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is  report  presents  an  evaluation  of  the  COPALbb 
lanquaoe  with  the  reouirements  lister!  in  the  "TINMAN". 
( DOI)  Peou i regents  For  Hiqp  Order  Computer  Pr oar amm i na 
Lanquaaes,  "TINMAN"  - 1 March,  197h,  Section  IV).  For 
purposes  o£  comparison  CORALbb  is  considered  to  be  de- 
fined by: 


Official  Definition  of  C0PAL66  Third  K.dition,  1974 


There  are  74  lanqua qe  requirements  listen  in  Section  4 of 
the  "TINMAN".  This  report  compares  CORAL66  with  each  in- 
dividual requirement.  A summary  of  the  deqree  to  which 
tne  lanquaqe  satisfies  each  requirement  is  presented. 

The  introductory  oaraaranh  of  each  "TINMAN"  requirement 
is  included  as  tne  leadinq  section  for  each  requirement 
eva 1 uat i on . 


Symbols  Placed  beside  eacn  individual  requirement  inui- 
cate  the  deqree  to  which  the  ianauaqe  meets  the  require- 
ment. Tne  symbols  and  rneir  meaninqs  are  as  follows: 

T - Totally  meets  requirement 

P - Partially  meets  require. ment 

F - Does  not  meet  requirement 

l)  - Unknown  trom  available  documentation 

A summary  of  the  evaluation  is  included  as  the  last  sec- 
tion of  this  report.  Merits  and  failures  of  the  lanouaoe 
as  it  currently  is  defined  are  discussed.  Also  oiscussed 
are  the  potential  Lanouaqe  modifications  that  can  be  made 
to  support  DO 0 "tinman"  requirements. 


on 


A.  DAI  A AND  TYPES 


Requirement:  A1 

The  language  will  oe  typed.  The  tvpe  Cor  mooe)  of  all 
variables,  components  of  composite  data  structures,  ex- 
pressions, ooerations,  and  parameters  will  be  rietermin- 
aDle  at  compile  time  and  unalterable  at  run  time.  The 
lanquaqe  will  require  that  the  type  of  each  variable  and 
component  of  composite  data  structures  be  explicitly 
specified  in  the  source  proaram. 


In  qeneral,  C0RAL66  is  a typed  lanouaae.  f,ost  types  are 
known  at  compile  time.  However,  two  specific  deficiencies 
exist  in  this  area.  Pointers  are  not  defined  explicitly 
as  pointers  nut  rather  as  inteqers.  Kloatino  point  vari- 
ables are  declared  as  inteaer  and  use  a software  language 
extension  to  perform  the  necessary  arithmetic  operations. 

Additionally,  the  OVERLAY  construct  provides  a method  for 
violatinj  type  cneckinq  and  verification. 

Addition  of  the  keyword  POINTER  to  the  lanouaae,  with  ap- 
propriate chanaes  to  the  syntax,  will  provioe  a method  of 
uniquely  identityinq  pointer  variables.  for  oetaileo  in- 
formation see  (Pf>). 

Similarly,  extension  of  tne  language  to  require  specific 
tyoinq  of  floatinq  point  nurrbers  can  be  accomplished. 

The  OVERLAY  option  can  be  restructured  within  the 
lanquaqe  out  tne  impact  on  existing  proorams  or  future 
proqrams  operatino  on  limited  machine  configurations  may 
preclude  this  option.  Development  of  a method  to  permit 
an  overlay  ooeration  and  also  preserve  tvre  checking  ap- 
pears to  be  very  expensive. 


Requirement:  A? 

The  lanquaqe  will  provide  data  types  tor  integer,  real 
(floating  point  and  fixed  point),  boolean  and  character 
and  will  provide  arrays  (i.e.,  composite  data  structures 
with  indexiole  components  of  homogeneous  type)  and 
records  (i.e.,  composite  data  structures  with  labeled 
components  of  heterogeneous  type)  as  type  generators. 


Integer T 

Fixed  point T 

Floating  point F 

Character  string T 

Hoolean F 

Arrays P 

Records P 


Floatinq  point  --  loatinq  point  variables  are  declared 
as  integer  type  in  tne  language.  Floatinq  ooirt  opera- 
tions are  implemented  as  procedure  calls  to  library 
routines. 

Boolean  --  Tnere  are  no  boolean  variables  and  no  bracket- 
ed boolean  exoressions  in  the  Coralpp  lamuaqe. 

Arrays  --  Arrays  are  provided  tor  witnin  the  lanquaqe. 
However,  arrays  are  limited  to  two  dimensions. 

Records  --  There  is  a provision  for  record  structures 
within  tne  lanouaae.  Records  are  definable  oy  a taole 
mechanism.  However,  records  do  not  nefine  types,  nor  may 
they  ne  used  as  type  constructors. 

The  lanquaqe  can  dp  modified  to  include  both  floatinq 
point  and  boolean  capabilities  at  modest  cost.  Expansion 
of  array  and  record  caoabi 1 i t ies , however  will  prove  to 
be  more  expensive. 


Requirement:  A3 


The  source  lanquaae  will  require  global  (to  a scope) 
speci f icat i on  of  the  precision  for  floatinq  point  arith- 
metic and  will  permit  precision  specification  for  indivi- 
dual variables.  This  specification  will  he  interpreted  as 
the  maximum  precision  required  oy  tne  program  Ionic  and 
the  minimum  Drecision  to  he  supported  oy  the  object  cooe. 


The  lanquaqe  does  not  include  this  capability.  Inclusion 
of  an  optional  sinole  floating  point  precision  declara- 
tion witnin  a olocK  that  pertains  to  all  local  floatinq 
point  identifiers  will  require  an  additional  lanauaqe 
Keyword,  PRfXISION,  which  would  he  used  as  follows: 


REG  I i'J 

FLOATING  PRECISION  IE-4  ; 

FLOATING  A,  b,  C ; 

The  following  rules  would  apply: 

1)  All  arithmetic  operations  on  local  (to  a scope) 
floating  variables  will  be  truncated  to  the  specified 
precision. 

2)  Operations  on  floating  data  between  local  and  non- 
local identifiers  will  pe  truncated  to  the  lower  preci- 
s 1 on . 

The  requirement  to  enable  individual  specification  of 
identifiers  would  still  not  be  met.  Precision  specifica- 
tion would  oe  considered  to  pertain  to  all  floatina  iden- 
tifiers declared  within  a aiven  nlocK. 


^ Requirement:  A4 

Fixed  Doint  numoers  will  oe  treated  as  exact  quantities 
which  have  a range  and  a fractional  step  size  which  are 
determined  by  tne  user  at  compile  time.  Scale  factor 
management  will  be  done  by  the  compiler. 


CORAL66  totally  meets  this  requirement. 


Requirement:  A5 

Character  sets  will  be  treated  as  any  other  enumeration 
type. 

A printing  cnaracter  is  assumed  to  have  a unique  inteoer 
representation  dependent,  on  some  hardware  or  software 
convention.  Tne  form  is  included  within  the  integer  syn- 
tax definition.  Printing  characters  are  implementation 
dependent.  Layout  characters  may  not  be  included  as  argu- 
ments of  literals. 


Requirement:  Ah 

The  language  will  require  user  specification  of  the 
number  of  dimensions,  the  ranqe  of  subscript  values  for 
each  dimension,  and  the  type  of  each  array  component. 
The  numoer  of  dimensions,  the  type  and  the  lower  sub- 
script bound  will  be  determinable  at  compile  time.  The 
upper  subscript  bound  will  be  determinable  at  entry  to 
the  array  allocation  scope. 


dumber  of  dimensions  fixed  at  compile  time T 

Type  fixed  at  compile  time 1 

Lower  subscript  bound  fixed  at  compile  time....! 

Subscripts  from  contiguous  range T 

Subscripts  from  enumeration  type P 

Upper  subscript  bound  fixed  at  scope  entrv F 


Subscripts  are  confine-)  to  Inteaer  type.  The  lanauage 
does  not  allow  an  explicit  cnaracter  as  a subscript.  See 
A 5 for  further  information. 

Arrays  are  limited  to  two  dimensions  and  are  fixed  at 
compile  time.  Addition  of  variable  upper  hounds  to  arrays 
will  require  extensive  change  to  the  ianguaae  definition. 


Requirement:  A7 

The  language  will  permit  records  to  have  alternative 
ttructures,  each  of  which  is  fixed  at  compile  time.  The 
4ame  and  type  of  each  record  component  will  be  specified 


^ 
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»y  the  user  at  compile  t i rr  e 


! 


« 
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Ajternative  structures  are  permitted  oy  the  use  of  the 
o»erlay  feature  and  oy  use  of  Pointers.  Components  must 
b»  specified  at  compile  time.  However,  type  checkjnq  and 
array  oound  protection  are  not  secure.  There  are  no  fa- 
cilities included  within  the  lanquaoe  to  identity  type 
disaareement s or  array  overruns  or  underruns.  Inclusion 
of  a discrimination  feature  will  require  extensive  res- 
tructuring of  the  formal  definition  of  the  lanouaae,  and 
indesd  may  not  he  economically  feasible. 


V 


V. 


H.  UPhRATIOrtS 


Requirement:  B 1 

Assimment  and  reference  operation  will  re  automatically 
defined  tor  all  data  types  which  do  not  manage  their  data 
storage.  The  assignment  operation  will  permit  any  value 
of  a aiven  type  t.o  be  assigned  to  a variable,  array  or 
recorc  component  of  that  type  or  of  a union  type  contain- 
ing t Tat  type.  Reference  will  retrieve  the  last  assigned 
value , 


VariaUe  declaration  for  all  data  types ..T 

Kncaosi  lated  type  declaration K 

Array  cr  record  declaration P 


Assionient  is  by  individual  variable  or  ty  individual  en- 
try wit,  in  tables  (records).  The  language  does  not  permit 
assignment  of  complete  arrays  or  records.  These  aims  may 
be  approached  hy  definition  of  user  written  procedures 
out  still  win  not  provide  a consistent  language  defini- 
tion an  1 notation. 


Reguiremi nt : B? 

The  source  language  will  nave  a built-in  operation  which 
can  be  used  to  compare  any  two  data  oojects  (reoaroless 
of  type)  for  identity. 


The  source  language  can  oe  used  to  compare  any  two  data 
ODjects  for  identity.  The  comparator  works  on  a bit  by 
bit  basis  witnout  regard  to  type.  This  m.eans  that,  con- 
ceivably, reals,  integers  and  characters  could  he  con- 
s idered  e iui valent . 


i 


Type  comparison,  within  the  constraints  of  the 


TINMAN 


for  equivalence  aid  a new  dimension  of  difficulty.  Limit- 
ed type  comparisons,  when  the  absolute  value  of  sub- 
scripts are  known  or  when  a specific  equivalence  rela- 
tionship is  explicitly  stated,  can  be  achieved.  However, 
use  of  pointers  and  overlay  features  tor  element  access 
provide  an  escace  .mechanism  from  type  equivalence  check- 
ing that  cannot  be  completely  avoided.  Practically  speax- 
inq,  either  the  rules  for  type  checking  must  De  relaxed 
or  the  constructs  permitted  in  the  language  must  be 
severely  restricted. 


Requirement:  Hi 

Relational  ooerations  will  be  automat ica 1 ly  defined  for 
numeric  data  and  all  types  defined  by  enumeration. 

p 

Ail  six  relational  operators  are  included.  Unoroereo  sets 
are  not  included  in  CURAl.bfi. 


Requirement:  B 4 

The  built-in  arithmetic  operations  will  include:  addi- 

tion, subtraction,  multiplication,  division  (with  a real 
result),  exponentiation,  inteqer  division  (with  inteaer 
or  fixed  point  arquments  and  remainder),  and  nenation. 

Addit  ion T 

Sub  t ract  i on 1‘ 

Multiplication T 

Division  (with  real  result)........!" 

Neqat  ion T 

Exponent  iation 1 

Division  witn  remainder F 

Exponentiation  is  not  suoported  in  the  lanquaqe. 
Remaihder  after  division  is  not  explicitly  available  in 
the  lanquaqe. 

Division  witn  remainder  can  be  included  by  the  addition 
of  a special  remainder  operator  and  the  appropriate  syn- 
tax modification. 

Exponentiation  capabilit. ies  can  also  be  included. 


Requirement:  8b 

Arithmetic  and  assignment  operations  on  data  which  are 
within  the  ranqe  specifications  of  the  prooram  will  never 
truncate  the  most  significant  digits  of  a numeric  quanti- 
ty. Truncation  and  rounding  will  always  be  on  the  least 
significant  digits  and  will  never  be  implicit  for  in- 
tegers and  fixed  point  numbers.  Implicit  roundina  beyond 


tne  specified  precision  will  be  allowed  for  floatino 
point  numbers. 

---U--- 

Truncation  rules  are  not  explicitly  discussed  in  the  for- 
mal definition  of  the  C0PAL66  language. 

Tne  assumption  is  made  tnat  most  of  the  truncation  rules 
specified  by  this  reouirement  are  met  since  they  are  gooo 
compiler  development  practices. 


Requirement:  bb 

Tne  built-in  boolean  operators  will  include  "AND" , "UR", 
"NUT",  and  "hUP".  The  operations  "AND"  and  "UP"  will  be 
evaluated  in  short  circuit  mode. 


Short  circuit  "AND" T 

Short  circuit  "OR" T 

NOT F 

NOR F 


The  operations  "NUT"  and  " NUR " are  not  included  within 
the  language.  Short  circuit  mode  evaluation  for  scalars 
is  defined  within  the  language. 

"NOT"  and  "NUR"  operators  can  oe  added  to  the  lanauaoe  at 
very  modest  cost. 


Pequirement:  87 

The  source  language  will  permit  scalar  operations  and  as- 
signment on  conformable  arrays  and  will  permit  data 
transfers  between  records  or  arrays  of  identical  logical 
structure. 


Assignment  between  records  and  arrays F 

Scalar  operations  on  arrays F 


The  lanauage  only  supports  element  by  element  access  of 
arrays  and  recorns.  The  capability  can  re  added  to  the 
language.  Again,  tyre  checking  tor  some  operations  can  be 
easily  included  but  use  of  pointer  and  overlay  capabili- 
ties can  still  provide  a method  to  circumvent  complete 
tyoe  checKing. 


Requirement:  U8 

There  will  be  no  implicit  type  conversions  but  no  conver- 
sion operation  will  be  required  when  the  type  of  an  actu- 
al parameter  is  a constituent  of  a union  type  which  is 
the  formal  parameter.  The  language  will  provide  explicit 


conversion  ooerations  among  integer,  fixed  point  and 
floating  point  aata,  between  the  oolect  representation  of 
numbers  and  their  representations  as  characters,  ano 
between  fixed  point  scale  factors. 


Explicit  conversions T 

No  implicit  conversions F 

fe-xplicit  between  scale  factors 1 


The  programmer  can  impose  any  desiren  system  of  evalua- 
tion by  tne  use  of  Number  type  ( bxoress  ion ) . If  no  expli- 
cit conversion  rules  are  specified,  implicit  lanouane 
rules  are  used  for  conversion.  Cnanges  to  elimin-ate  the 
imblicit  conversion  capability  will  have  minimal  impact. 


Kenuirement:  B4 

Explicit  conversion  operations  will  not  be  required 
between  numerical  ranges.  There  will  oe  a run  time  excep- 
tion condition  when  any  integer  or  fixed  point  value  is 
truncated. 


The  language  does  not.  sunport  this  function. 

Tne  capability  for  run  time  exceDtion  checxinq  can  be  in- 
cluded within  the  language. 


Requirement:  BIO 

The  Dase  language  will  Drovide  operations  allowing  pro- 
grams to  Interact  with  files,  channels  or  devices  includ- 
ing terminals.  These  operations  will  permit  sending  ard 
receiving  both  data  ana  control  information,  will  enable 
programs  to  dynamically  assign  and  reassign  I/O  devices, 
will  provide  user  control  for  exception  conditions,  and 
will  not  be  Installation  dependent. 

Tne  language  does  not  exDlicitly  define  I/O  operations. 
All  operations  are  accomplished  by  calls  to  procedures 
which  are  tailored  to  the  required  hardware  configura- 
tion. Language  constructs  can  be  defined  to  satisfy  this 
reauirement.  There  are  however,  complications  and  machine 
dependency  problems.  Bit  manipulat ion  constructs  provid- 
ed oy  tne  language  can  be  used  to  generate  programs  that 
are  machine  dependent,  while  this  violates  "T1NVAN"  con- 
straints, tnis  capability  is  necessary  in  many  applica- 
t ions . 


Reauirement : B1 1 

The  language  will  provide  operations  on  data  types  ae- 


fined  as  power  sets  of  enumeration  types  (see  16).  These 
operations  will  Include  union,  intersection,  difference, 
complement,  and  an  element  predicate. 


Power  sets  are  not  defined  in  the  language.  This  caoapii- 
ity  can  oe  added  with  not  too  much  difficulty. 


C.  KXPRFSS TONS  AMP  P ARA^FTKPS 


Peouirement:  Cl 

Side  effects  which  are  dependent  on  trie  evaluation  order 
among  the  arguments  of  an  expression  will  be  evaluated 
lef  t-to-r ight . 

Alt.nouah  an  algorithm  tor  evaluating  expressions  does  not 
form  part,  of  the  formal  definition  of  the  languaae,  all 
syntacti cal ly  outermost  terms  in  an  expression  will  be 
evaluated  to  the  required  numeric  tyoe  before  the  adding 
ODerators  are  apolied.  However,  if  an  expression  is  en- 
closed in  round  oracxets,  its  terms  are  no  longer  'outer- 
most* and  the  rule  no  longer  applies.  In  this  case  the 


aiaorithm  for  the  particular  compiler  determines  the  se- 
quence of  events.  Aorii t iona  1 ly  , the  programmer  may  impose 
any  desired  system  of  evaluation. 


Requirement:  C? 

Which  parts  of  an  expression  constitute  the  operands  to 
each  operation  within  that  expression  should  be  onvious 
to  the  reader.  There  will  be  few  levels  of  operator 
hierarchy  and  they  will  ne  widely  recognized. 


Unambiguous  presentation P 

Pew  precedence  levels r 

Require  explicit  parentneses F 

No  user  defined  levels T 


Precedence  levels  are  tnose  normally  encountered  in  all 
languaaes.  The  language  can  pe  modified  to  require 
parentheses  in  certain  cases  if  the  list  of  cases  can  oe 
agreed  uoon  by  all  users. 


Requirement:  C 3 

Expressions  of  a given  type  will  be  permitted  anywhere  in 
source  programs  where  noth  constants  and  references  to 
variables  of  that  type  are  allowed. 


There  are  no  special  case  constraints  on  expressions  in- 
cluded in  the  syntax  of  the  language. 


Requirement:  C4 

Constant  expressions  will  be  allowed  in  programs  where 
constants  are  allowed,  and  constant  expressions  will  be 
evaluated  before  run  time. 


The  requirement  is  completely  met  by  the  language. 


Requirement:  Cb 

There  will  be  a consistent  set  of  rules  applicable  to  all 
parameters,  whether  they  be  for  procedures,  for  tyres  tor 
exception  handlino,  for  parallel  processes,  for  declara- 
tion, or  for  built-in  operators.  There  will  be  no  spe- 
cial operations  (e.g.,  array  structuring)  applicable  only 
to  parameters. 


Consistency  in  parameter  rules 


P 


vio  special  parameter  operations 


1 


exception  handlin?  and  parallel  Processing  are  nor  expli- 
citly addressed  within  the  language. 

The  forrrai  parameter  and  the  passed  Parameter  must  agree 
in  type  according  to  language  rules.  However,  as  was  the 
case  in  requ i r ement  A1 , this  type  checking  can  be  defeat- 
ed by  use  ot  pointers  and  computed  array  or  table  loca- 
tion values. 


Requirement:  C 6 

Formal  and  actual  parameters  will  always  aqree  in  type. 
The  number  of  dimensions  for  array  parameters  will  be 
determinable  at  compile  time.  The  size  and  subscript 
ranqe  for  array  parameters  need  not  be  determinable  at 
compile  time,  but  can  te  passed  as  part  ot  the  parameter. 

p 


Dimensions  determined  at  compile  time I 

Size  and  subscripts  can  oe  passed..... K 

Tyne  aqreement  for  actual  and  formal  parameters P 

In  general  tnere  is  aqreement  of  type  between  formal  and 
actual  parameters.  Use  of  computed  subscripts  and  use  of 
pointer  capabilities  still  provide  metnods  for  defeating 
type  checking  in  all  cases. 

Tne  languaqe  can  oe  modified  to  pass  array  size  and  sub- 
scripts as  arguments  and  the  capability  to  support  more 
than  two  dimensional  arrays  can  be  included. 


Requirement:  C7 

fnere  will  be  tour  classes  of  formal  parameters.  For 
data  there  will  be  those  which  act  as'  constants 
representing  the  actual  parameter  value  at  time  of  call, 
and  those  which  rename  tne  actual  parameter  which  must  be 
a variable.  In  addition,  there  will  oe  a formal  parame- 
ter class  tor  specifying  the  control  action  when  excep- 
tion conditions  occur  and  a class  tor  Procedure  parame- 
ter s . 


Parameter  constants T 

Parameter  variables T 

Exception  conditions P 

Procedure  parameters T 


The  constructs  VALUE,  LOCATION,  and  LABEL  identify  tne 
input,  output  and  exception  handling  capabilities  ot  the 
language.  Exception  control  is  supported  by  use  of  label 
parameters.  There  is  no  formal  classification  of  excep- 
tion parameters  specified  within  the  language. 


k 


Requirement:  CR 

Sneci f icat ion  of  the  tyoe,  range,  precision,  dimension, 
scale  d.n'i  format  of  parameters  will  ce  optional  on  the 
formal  sine.  None  of  them  will  he  alterable  at  run  time. 

Optional  properties ..P 

Fixed  at  run  time F 

Panae  and  dimension  of  arrays  and  tables  cannot  he  speci- 
fied within  procedure  definition.  All  other  properties 
must  be  specified. 

it  is  not  apparent  to  the  reviewer  how  this  reauirement 
can  be  acnieved  and  the  requirements  of  A1  and  A 7 simul- 
taneously achieved;  per naps  a special  construct,  GENERIC , 
to  be  used  only  bv  an  elite,  tigntiv  controlled  oroup  of 
oroorammer s . 

Support  of  this  capability  reauires  a significant  chanoe 
to  t.ne  syntax  of  the  COR  ALE  6 lanquaqe. 


Requirement:  C9 

There  will  be  provision  for  variaole  numbers  of  arou- 
ments,  Dut  in  such  cases  all  but  a constant  number  of 
them  must  be  of  the  same  tvre.  whether  a routine  can 
have  a hummer  of  arauments  must  be  determinable  from  its 
description  and  the  number  of  arguments  for  any  call  will 
be  determinable  at  compile  time. 

F 

Variable  numper  of  arguments F 

All  but  constant  number  same  type F 

dumber  fixed  at  compile  time T 

The  number  of  arguments  tor  all  procedures  is  fixed  at 
comDile  time.  In  one  sense,  passing  of  a formally  de- 
clared array  name  as  an  arqument  provides  access  to  a 
variable  number  of  arguments.  This  apparently  is  not  the 
intent  of  this  requirement  but  could  be  -judiciously  used 
to  partially  satisfy  it. 


The  syntax  of  the  language  can  be  changed  to  support  this 
requirement  out  the  magnitude  of  the  change  indicates  an 
almost  complete  redefinition  of  segments  of  the  language. 
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L).  VARIABLES,  LitLRALS  AND  CONSTANTS 


Requirement:  D1 

The  user  wiiL  nave  the  ability  to  associate  constant 
values  of  any  type  with  identifiers. 


Tne  lanquaqe  provides  this  capability. 


Requirement:  0? 

The  lanquaae  will  provide  a syntax  and  a consistent  in- 
terpretation for  literals  of  built-in  data  types.  Numer- 
ic literals  will  have  the  same  value  (within  the  speci- 
fied Precision!  in  both  proorams  and  data  (input  or  out- 
out). 

P 


Literals  of  ouilt-in  data  types P 

Consistency  in  value P 


Floatino  point  numbers  cannot,  be  compiled  since  the  com- 
piler works  only  in  fixed  point.  The  existino  documenta- 
tion is  unclear  as  to  whether  the  values  of  literals  are 
a function  of  compile  time,  run  time  or  both. 


£ 
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Peouirement:  03 

The  lanquaae  will  permit  tne  user  to  specify  the  initial 
values  of  individual  variables  as  oart  of  their  declara- 
tion. Such  variables  will  be  initialized  at  tne  time  of 
tneir  apparent  allocation  (i.e.,  at  entry  to  allocation 
scope).  There  will  be  no  default  initial  values. 


Declare  initial  values R 

Allocation  scope  initialization P 

No  default  values T 


Certain  data  oblects  may  be  initialized  *hen  the  proaram 
is  loaded  into  storaoe  by  use  of  tne  presettinq  clause  in 
the  data  declaration.  Presettinq  is  not  dynamic,  and 
preset  values  which  are  altereo  by  proaram  execution  are 
not  reset  unless  the  seqment  or  proqram  is  reloaded.  An 
object  is  not  elidible  for  presettinq  if  it  is  declared 
anywhere  within 

1)  the  oody  of  a recursive  orocedure  or, 

2)  an  inner  block  of  the  proaram  or, 

3)  an  inner  block  of  a procedure  oodv. 

Requirement:  D4 
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The  source  language  will  require  its  users  to  specify  in- 
dividually the  ranae  of  all  numeric  variables  and  the 
steD  size  for  fixed  point  variables.  The  range  specifi- 
cations will  be  interpreted  as  the  maximal  raroe  which 
must  be  suooorted  by  the  object  code.  Range  and  step 
size  specifications  will  not  be  interpreted  as  riefininn 
new  types. 

There  is  no  capability  specified  within  the  language  for 
range  checking. 

The  compiler  can  oe  expanded  to  include  ranne  creeping 
mechanisms.  Checks  for  compile  time  usage  can  be  included 
with  relatively  little  cost.  Run  time  checks,  however, 
will  reouire  an  extensive  overhaul  of  compiler  svntax. 


Reouirement:  05 

The  range  of  values  which  can  be  associated  with  a vari- 
able, array,  or  record  component  will  be  any  built-in 
type,  any  defined  type  or  a contiguous  subseouence  of  anv 
enumeration  type. 


The  language  does  not  provide  this  capability.  It  can  be 


added  as  a sunset  of  the  potential  additions  discussed  in 
04.  The  Language  has  a very  limited  arrav/table  capabili- 
ty. Only  two  dimensional  arrays  are  permitted.  There  is 
limited  capability  tor  the  interrelation  of  arrays  ana 
records.  A major  restructuring  of  tne  lanauaoe  will  oe 
necessary  to  meet  the  intent  of  the  "TINMAN"  reouire- 
ments . 


Reouirement:  06 

The  language  will  provide  a pointer  mechanism  which  can 
be  used  to  build  data  with  shared  and/or  recursive  sub- 
structure. The  pointer  property  will  onlv  affect  tne  use 
of  variaoles  (including  array  and  record  components)  ot 
some  data  types.  Pointer  variables  will  be  as  safe  in 
tneir  use  as  are  any  other  variables. 


Shared/recursive  substructure  capability T 

far iable/record/array  component  nandlino T 

Typed  pointer  char acter  i s t.  i c h 

Allocation  never  wider  than  access F 


Tne  pointer  capability  orovided  dv  CURAl.nb  is  wide  open. 
Virtually  no  cneckino  ot  tvpe  or  access  scone  is  possi- 
ble. Pointers  are  defined  as  integers  and  thus  may  take 
on  anv  value  permitted  an  integer.  It  is  possible  to  ac- 
cess any  core  location  by  mistake  usino  tne  pointer. 

in  order  to  satisfy  "TINYAiv"  r eaui  rements , several  addi- 


tions  must  be  made  to  the  syntax  of  the  compiler.  First, 
the  pointer  must  be  typed  explicitly  as  such.  Next,  the 
rules  qoverninq  pointer  use  must  be  defined.  In  this  case 
pointers  should  oe  limited  to  record  or  array  structures 
*ith  a series  of  restrictions  limitlnq  the  ranoe  of 
values  the  pointer  may  taxe.  These  restrictions  should 
preclude  computational  assiqnmeot  of  value  to  the 
pointer.  Values  should  be  limited  by  fe  compiler  to 
tnaf  set  *hich  is  completely  fno*n  at  comnj'n 

Obviously  this  will  severely  limit  tne  pc*er  ard  useful- 
ness of  pointers  but  strinqent  type  chectinq  and  scope 
checking  demand  this  limitation. 


F . OFF  I N I T T DM  FACILITIES 


Requirement:  El 

The  user  o£  the  lanquaoe  will  he  able  to  define  new  data 
tvoes  and  operations  within  his  programs. 


This  requirement  is  not  supported  by  the  lanquaae.  New 
data  types  may  ne  introduced  implicitly  by  definition  o* 
procedures  to  perform  the  function  of  a new  data  tyce.  Tr. 
this  case,  however*  tvoe  checking  and  allocation  scone 
checking  rules  can  easily  be  violated. 


Requirement:  E? 

The  "use"  of  defined  types  will  be  ind J st i rou i snap l e from 
built-in  types. 

The  lanquaie  does  not  permit  definition  of  new  data  tvnes 
as  an  operation. 

This  capability  can  ne  added  to  the  lamuaoe  as  an  exten- 
sion of  El. 


Requirement:  El 

Each  nroqram  component  will  be  defined  in  the  base 
lanouaqe,  in  a library,  or  in  the  nroqram.  There  will  be 
no  default  declarations. 

C0PAL66  completely  meets  this  requirement. 


Reaui rement : E4 

The  user  will  he  aole,  within  the  source  lanouaae,  to  ex- 
tend existinq  operators  to  new  data  tyres. 


The  language  does  not  permit  new  type  definition.  This 
capability  can  be  included  as  oart  of  the  extension  to 
t vne  definition. 


Requirement:  E5 

Tvoe  definitions  in  the  source  lanquaqe  will  permit  de- 
finition of  Doth  the  class  of  data  oblects  comprising  the 
tvoes  and  the  set  of  operations  applicable  to  that  class. 


A defined  type  will  not  automatically  inherit  the  opera- 
tions of  the  data  with  which  it  is  represented. 


The  lanauaae  does  not  support  user  defined  types. 


Rpqui rempot : Ffc 

The  data  oolects  comprising  a defined  type  will  he  defin- 
able by  enumeration  of  their  literal  names,  as  Cartesian 
products  of  existina  types  (i.e.,  as  array  and  rpcord 
classes),  by  di  scr  i m i nat  ed  union  (i.e.,  as  the  union  of 
disjoint  tyoes)  and  as  the  rower  set  of  an  enumeration 
type.  These  definitions  will  ne  processed  entirely  at 
como  i 1 e time. 


Fnump  r a t ion F 

Cartesian  products T 

Discriminated  union F 


Power  set  of  enumeration  tyoe..,.F 

The  table  mechanism  is  used  to  define  records.  Its  use  is 
limited,  however.  Records  do  not  define  fyoes  and  cannot 
be  used  as  tyoe  const ructors. 

Arrays,  as  nas  been  mentioned  refore,  are  limited  to  two 
dimensi ons  . 

The  lanauaae  may  be  modified  to  suoport  this  reouirement. 
Table  and  array  structures  are  verv  limited  within  the 
lanauaae  and  should  be  expanded. 


Reauirement : F.'J 

Tyoe  definitions  pv  free  union  (i.e.,  union  of  non- 
disjoint  tvnesl  and  subsettina  are  not  desired. 


Does  not  permit  free  unions F 

Does  not  permit  subsettina T 


Free  unions  are  oermitted  with  use  of  pointer  and  overlay 
functions  within  the  lanauaae. 

Subsettina  is  not  defined  within  the  lanauaae. 


Requirement:  E P 

When  defininq  a tvr>p,  the  user  will  he  able  to  snecifv 
the  initialization  and  finalization  procedures  for  the 
tvne  and  the  actions  to  oe  ta^en  at  the  time  of  alloca- 
tion and  deallocation  of  variables  of  that  type. 


Types  cannot  op  defined  within  the  lanouaoe. 


F.  SCOFFS  AMO  I.IPWARTKS 


Peou  t rement : FI 

The  lanouaoe  will  allow  the  user  to  dlstinouisn  between 
scone  of  allocation  and  scope  of  access. 

Ini tial i zat i on  of  variables  is  accomplished  hv  a common 
communicator  used  nv  the  system,  ini t i al i zat ion  is  per- 
formed only  once  under  the  rul°s  stated  in  03. 

nut  of  scone  access  to  variables  is  possible  when  usina 
tne  pointer  facility  of  the  lanouaoe. 


beouirement:  F 7 

The  ability  to  limit  the  access  to  seraratelv  affined 
structures  will  be  available  both  where  the  structure  is 
defined  and  where  it  is  used.  It  will  nr  possible  to  as- 
sociate new  local  names  with  seoarateiv  defined  prooram 
components . 

As  previously  stated,  tne  lanouaoe  does  not  support  de- 
finition of  new  data  types. 

Tne  lanouaoe  does  not  distimuish  oetween  norm, a]  struc- 
tures and  "soecial"  structures.  The  lanouaoe  can  certain- 
ly be  modified  to  include  such  a capability  but  it  will 
be  costly. 


Peauirement:  F3 

The  scooe  of  identifiers  will  be  wholly  determined  at 
comni le  time. 


This  reouiremenf.  is  completely  met  by  the  lanouaoe 


Reiuirement:  F 4 


a variety  of  app  1 i cat  ion-or i enter)  data  and  operations 
will  ne  available  in  libraries  and  easily  accessible  in 
the  language. 


Variety  of  data  and  operations P 

Easily  accessible T 


The  language  documentation  mentions  a number  of  pro- 
cedures and  routines  that  are  available,  i'.hetner  the  li- 
braries contain  all  thinas  desired  bv  this  reouirement.  is 
not  determined. 

The  cost  of  orovidinq  a "variety"  can  ranoe  from  modest 
to  exhorbitant,  depending  on  what  functions  are  con- 
sidered necessary. 

Available  routines  are  easily  accessible  to  the  Droaram- 
mer . 


Requirement:  FS 

Proaram  components  not  defined  within  the  current  program 
and  not  in  the  base  language  will  be  maintained  in  com- 
pile time  accessible  libraries.  The  libraries  will  be 
capable  of  holding  anything  definable  in  the  lanauaae  and 
will  not  exclude  routines  whose  hodies  are  written  in 
other  source  languages. 


Accessible  at  compile  time T 

other  source  language  routines P 


The  language  does  not  preclude  routines  written  in  a dif- 
ferent source  language.  As  long  as  the  routines  exist  in 
an  oblect  form  compatible  with  CURAL66  they  can  reside  1 r. 
system  libraries.  There  is  no  provision  for  interface 
checking  in  the  language. 


Requirement:  F 6 

Libraries  and  Comnools  will  be  indistinguishable.  They 
will  be  capable  of  holding  anything  definable  in  the 
language,  and  it  will  be  possible  to  associate  them  with 
anv  level  of  programming  activity  from  systems  through 
orolects  to  individual  nroorams.  mere  will  be  many  spe- 
cialized comoools  or  libraries  any  user  specified  subset 
of  which  is  immediately  accessible  from  a given  rrooram. 

- — F 


Libraries  and  comnools  indi  st  1 naui  sbable F 

Hold  anything  definable  in  lanouaoe T 

Many  levels  of  access t 

•ianv  specialized  subsets P 


r 


The  seaments  of  a oroaram  may  commun i cate  with  each  other 
throuoh  a coition  dlona  1 object  set  and  with  objects 
external  to  the  orooram  bv  means  of  communicator s such  as 
library,  external  or  absolute  identifiers  as  defined  in 
oarticular  implementations. 

Subsets  may  be  defined  nut  whether  there  are  "many"  is 
open  to  individual  interpretation. 


Heouirement:  F7 

The  source  lanquaqe  will  contain  standard  machine  in- 
dependent. interfaces  to  machine  dependent  capab i 1 i t i es  , 
includinq  peripheral  equipment  and  special  hardware. 

Inclusion  of  such  a capability  within  the  lanouane  will 
depend  noon  tne  choice  of  a standard  set  of  interfaces. 
Cost  of  this  effort  is  even,  more  dependent  upon  this 
choice. 


G.  CONTROL  STRUCTURES 


Requirement:  G1 

The  lanouaqe  w i 1 1 provide  structured  control  mechanisms 
for  sequential,  conditional,  iterative,  and  recursive 
control.  It  will  also  nrovide  control  structures  for 
(oseudo)  Parallel  processim,  exception  handlinq  and 
asynchronous  interrupt  nandlinq. 


Sequential  control T 

Conditional  control f 

Iterat  ion T 

Recursion I 

Parallel  processim i 

Excertion  handlinq P 

ftsyncronous  interrupts P 


The  lamuaqe  provides  the  following  keywords  for  control 
mechan i sms : 

DO 

EOR 

GOTO 

IF 

WHILE 

Exception  handlinq  is  orovioed  bv  use  of  parameter  la- 
bels. This  does  not  explicitly  provide  all  the  capability 
required  but  does  provide  a modest  start  for  attainina 
the  caoabi 1 ity. 

The  lanouaae  does  not.  orovide  an  explicit  mechanism  for 
interrupt  handlinq.  Extra  facilities  and  extensions  are 
available  to  include  the  oeneration  of  multi-level  nro- 
qrams,  i.«.,  those  which  run  under  several  interrupt  lev- 
els. 

Similarly,  there  is  no  explicit  definition  of  parallel 
processim.  addition  of  this  to  the  structure  of  the 
lamuaqe  will  require  malor  lanouaae  modification. 

In  oeneral,  the  lanquaoe  does  not  explicitly  specify  how 
any  of  the  above  requirements  should  be  met.  Parts  of 
these  requirements  can  r>e  met  by  use  of  lamuaqe  capabil- 
ities provided  for  different  functions  --sort  of  twisting 
the  intent  of  the  lanquaoe  as  it  were. 


Requirement:  G? 

Tne  source  lanouaae  will  orovide  a "oo  to"  operation  ap- 
plicable to  Drooram  labels  within  its  most  local  score  of 
detin j t ion. 

P — 


Go  to  transfers  are  to  labels  defined  within  the  local 
scope  of  eacn  oronram  block-.  Labels  are  suhiect  to  the 
same  rules  as  variables.  Thus  the  "ao  to"  statement  Per- 
mits iumos  from  an  inner  to  an  outer  block-  or  within  the 
same  blocK  out  not  from  an  outer  to  an  inner  block. 

Mules  novernim  the  "no  to"  operation  can  be  modified  to 
preclude  branches  out  of  scone  but  then  a new  mechanism 
for  exceDtion  Drocessim  must  be  defined. 


Menu i r ement : G) 

The  conditional  control  structures  will  he  -fully  parti- 
tioned and  will  Permit  selection  arnom  alternative  compu- 
tations based  on  the  value  of  a Boolean  expression,  on 
the  subtvne  of  a value  from  a discriminated  union,  or  on 
a computed  choice  amom  labeled  alternatives. 


Based  on  boolean  expression T 

Based  on  type  from  discriminated  union F 

Based  on  computed  choice P 

An  "else"  clause  is  not  manditory  for  all  "if-then"  ex- 
pressions. It  may  or  mav  not  be  used. 

A computed  choice  for  "do  to"  is  provided  by  the  "switch" 
function.  No  mention  is  made  of  what  happens  if  the 
switch  value  is  outside  the  ranae  of  statement  numpers. 

There  are  no  simple  mechanisms  for  common  cases. 


Reauirement:  G4 

The  iterative  control  structure  will  permit  the  termina- 
tion condition  to  appear  anywhere  in  the  looo,  will  re- 
auire  control  variables  to  be  local  to  the  iterative  con- 
trol, will  allow  entry  only  at  the  head  of  the  loop,  and 
will  not  impose  excessive  overhead  in  clarity  or  run  the 
execution  costs  for  common  special  case  termination  con- 
ditions (e.d.  fixed  number  of  iteration  or  elements  of  an 
array  exhausted). 

P 


Termination  anywhere  in  loop T 

Local  control  variables F 

F.ntry  at  looo  head  only... T 

Efficient  and  clear  simnle  cases T 


Control  value  available  at  termination F 

Termination  within  a loop  is  made  oossinle  bv  several 
constructs  within  the  lanquade. 

Syntax  rules  do  not  explicitly  stare  whether  loons  are 
entered  only  at  the  too. 


The  control  variable  mav  or  m av  not  occur  within  the  con- 
trol l pd  statement.  The  controlled  variable  is  a word 
reference,  i.e.,  either  an  anonymous  reference  or  a de- 
clared word  reference.  The  value  of  the  controlled  vari- 
able is  available  for  declared  word  references.  Syntax 
rules  exDiicitlv  define  the  order  for  i ncrerrentat  ion . 

Syntax  for  iterative  evaluation  can  be  redone  to  com- 
pletely meet  " T T •)  m A " r e qu  i r pm e n t s . 


Reau i r ement : GS 

Recursive  as  well  as  nonrecursive  routines  will  be  avail- 
able in  the  source  lanauaoe.  Jt  will  not  be  possible  to 
define  procedures  within  the  nody  of  a recursive  pro- 
cedure. 


Recursive  and  nonrecursive  routines T 

Exnlicitlv  soecifv  recursive  routines T 

No  nested  recursive  procedures U 


l.anauaae  syntax  does  not  state  whether  procedures  nay  be 
defined  within  the  body  of  recursive  procedures.  If  so  it 
is  an  easv  task  to  restructure  the  language  to  prohibit 
this  capability. 


Reou i rement : Gb 

The  source  language  will  Droviae  a parallel  nrocessina 
capaoility.  This  capability  should  include  the  ability 
to  create  and  terminate  (possible  pseudo)  parallel 
processes  and  for  these  processes  to  aain  exclusive  use 
of  resources  during  specified  portions  of  their  execu- 
tion. 


The  language  does  not  explicitly  address  parallel  pro- 
cessing reou i rement s . 


Reau i rement : G7 

The  exception  handling  control  structure  will  permit  the 
user  to  cause  transfer  of  control  and  data  for  anv  error 
or  exception  situation  which  might  occur  in  a orooram. 

CORAt.bfe  does  not  explicitly  include  constructs  for  excep- 
tion control  handling.  The  onlv  mechanism  provided  bv  the 
language  is  the  capability  to  nass  addresses,  as  l.ARFL 
parameters,  for  what  routine  to  enable  in  the  evert  of  an 
except i on . 


Addition  of  exceotion  control  constructs  to  the  language 


will  be  a costly  process. 


Requirement:  G 8 

There  will  be  source  lanauaue  features  which  permit  delay 
on  anv  control  oath  until  some  specified  time  or  situa- 
tion has  occurred,  which  permit  specification  of  the  re- 
lative priorities  amona  parallel  control  paths,  which 
qive  access  to  real  time  clocks,  which  permit  asynchro- 
nous hardware  interrupts  to  be  treated  as  anv  other  ex- 
ception situation. 


This  requirement  appears  to  expand  on  the  G6  require- 
ments. Parallel  orocessinu  capabilities  can  he  added  to 
tne  lanquaje.  This  addition  will  be  costly  and  may  tend 
to  cloud  the  readability  and  clarity  of  the  lanouaoe. 


H.  SYNTAX  AND  r (HI ME NT  CONVENTIONS 


: • 
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Requirement:  HI  1 

The  source  lanauaqe  will  be  free  format  w 1 1 h an  explicit 
statement.  seoarator,  will  allow  the  us®  of  mpemonical ly 
siqnificant  identifiers,  will  be  based  on  conventional 
forms,  will  have  a simple  uniform  and  easily  parsed  qram- 
mar,  will  not  provide  unique  notations  tor  special  cases 
will  not  permit  abbreviation  of  identifiers  or  tev  words, 
and  will  dp  syntactically  unambiguous. 


free  format  with  statement  separator r 

vnemonically  significant  identifiers T 

Conventional  forms T 

Simple  uniform  qrammar I 

'Jo  special  case  notations P 

No  abbreviation  of  Keywords  or  identifiers....! 
Unambiquous  qram-nar P 

Square  brackets  as  used  with  pointers  and  switch  func- 


tions tended  to  confuse  the  evaluator  occas i ona 1 1 v . Also, 
the  differentiation  between  the  uses  of  square  and  round 
brackets  was  occasionally  misleadina.  These  however,  are 
very  minor  points. 



. 

Requirement:  H? 

The  user  will  not  be  able  to  -modify  the  source  lanauaqe 
syntax.  Specifically,  ne  v;  1 1 1 not  be  able  to  modify 
operator  hierarchies,  introduce  new  precedence  rules,  de- 
fine new  kev  word  forms  or  define  new  infix  operator  pre- 
cedence . 


The  syntax  is  completely  fixed. 


Requirement:  HI 


y 

*5 

jr. ■ 

t- 

* 


The  svnt.ax  of  source  lanauaae  oroarams  will  be  comoosable 
from  a character  set  suitable  tor  publication  purposes, 
but  no  feature  of  the  lanauaqe  will  ne  inaccessible  usinc 
the  f> 4 character  ASCfl  subset. 


«» 


N: 


The  lanauaqe  satisfies  this  requirement. 


Requirement:  H4 

The  lanauaqe  definition  will  provide  the  formation  rules 
for  identifiers  and  literals.  These  will  include 


literals  for  numbers  and  character  strlms  and  a break 
character  for  use  internal  to  identifiers  and  literals. 


Literals  for  numbers T 

Character  strings T 

break  character F 


The  language  does  not  contain  a break  character  but  can 
be  mooified  to  include  one. 


Requirement:  d 5 

There  a i 1 1 be  no  continuation  of  lexical  units  across 
lines,  out  there  will  be  a wav  to  include  object  charac- 
ters sucn  as  end-of-line  in  literal  strinas. 

Multiple  lines  are  permitted  within  tne  lanquaae  struc- 
ture. It  should  be  verv  simple  to  change  this  feature. 


Requirement:  Hb 

Key  words  will  be  reserved,  will  be  very  few  in  number, 
will  be  informative,  and  will  not  ne  usable  in  contexts 
where  an  identifier  can  ne  used. 

Tne  language  defines  i?  *ev  *or ds  which  seems  to  be  few 
enouah . 


Peau i rement : H7 

The  source  language  will  nave  a sinole  uniform  comment 
convention.  Comments  will  be  easily  rii st inaui shable  from 
code,  will,  be  introduced  by  a single  (or  possiblv  two) 
language  defined  characters,  will  permit,  any  combination 
of  characters  to  appear,  will  he  anle  to  appear  anywhere 
reasonable  in  programs,  will  automat ical 1 y terminate  at 
end-of-line  if  not  otherwise  terminated,  and  will  not 
prohibit  automatic  reformatting  of  programs. 

p 


Single  comment  convention F 

Distinguishable  from  code P 

Introduced  by  one  or  two  characters f 

Contain  any  charcter P 

^oDear  anywhere  reasonable T 

Terminate  at  end  of  line F 

Mot  prohibit  reformatting T 


Comments  may  be  expressed  in  two  forms;  either  preceded 
by  the  word  CQMMFMT  or  enclosed  in  round  brackets  follow- 
ing a program  statement.  This  can  he  easily  changed  to 


meet  the  r etiu i rement . 

As  noted  above,  more  than  two  letters  are  required  to  In- 
troduce a comment.  Additionally,  multiple  line  comments 
tend  to  confuse  the  reader  of  complex  proorams  written  in 
tne  lanquaqe.  These  faults  can  be  easily  eliminated  bv 
modifvinq  the  lanou ane  to  conform  to  "Tlf:vAN"  require- 
ments . 


Requirement;  HR 

The  lanauaqe  w i 1 1 not  permit  unmatched  parentheses  of  any 
k i nd . 


Requirement;  H9 

There  will  be  a uniform  referent  notation. 

The  lanauaqe  employs  square  brackets  in  referrino  to 
members  of  arrays  or  taoles  and  rouno  brackets  in  defin- 
inq  procedure  parameters.  The  complete  intent  of  this  re- 
quirement mav  not  be  met,  however,  we  feel  that  mis  is  a 
minor  variation. 


Requirement;  410 


Uo  lanquaqe  defined  symbols  appearino  in  the  same  context, 
will  have  essentially  different  meaninos. 


mm*-  — nf.  m 




* I.  DFFAIJLTS,  CONDITIONAL  COMPILATION,  AMO  LANGUAGF  RES- 
TRICTIONS 


Requirement:  II 

There  will  be  no  defaults  in  oroqrams  which  affect  the 
Dronram  loaic.That  Is,  decisions  which  affect  proaram 
loqic  will  be  made  either  irrevocably  when  the  lanouaae 
is  defined  or  explicitly  in  each  proaram. 

This  requirement  is  satisfied  by  the  lanquaae. 


Requirement:  12 

Defaults  will  be  orovided  for  special  can abilities  af  - 
fectina  only  obiect  reoresentat i on  and  other  properties 
which  the  oroorammer  does  not  know  or  care  about.  Such 
defaults  will  always  mean  that  the  Droorammer  does  not 
care  which  cnoicp  is  made.  The  programmer  will  be  able 
to  override  these  defaults  when  necessary. 

P 

In  aeneril,  the  lanquaae  does  not  Dermit  defaults.  Howev- 
er, there  are  some  exceptions.  For  example,  recursion  is 
treated  is  a procedure  for  compilers  lackinn  fhe  recur- 
sion fe.ture.  Floating  point  is  treated  as  trteaer  for 
compilers  not  including  floatinq  point  capability.  In  all 
cases  of  this  sort  the  programmer  is  advised  of  defaults. 


Requ i re  tent : 1 ) 

The  user  will  be  able  to  associate  compile-time  variables 
with  Prtarams.  These  will  include  variables  which  speci- 
fy the  (blect  computer  model  and  other  aspects  of  the  ob- 
iect machine  conf iourat i on  , 

The  co toiler  language  does  not  support  explicit  specifi- 
cation of  tne  obiect  machine.  These  capabilities  can  be 
added  to  the  lanquaae,  but  at  some  expense.  There  is  a 
definite  need  for  an  explicit  method  to  specify  word 
sizes,  number  of  bits  oer  word,  bit  sizes  for  address 
formul,s,  and  other  machine  dependent  features. 


Case  statements  ere  not  used  for  conditional  evaluation, 
rner » are  certain  procedures  available  to  structure  the 
oroaram  to  the  obiect  machine.  For  example,  floating 
point  ooerations  are  defined  as  inteaer  for  those 
machines  with  no  floating  ooint  hardware.  Recursive  pro- 
cedures default  to  procedures  on  those  machines  not  hav- 
ino  the  recursion  oackaae  available,  nther  options  may  be 
available  but  are  not  described  in  the  evaluation  docu- 
ment t ion . 

All  (ossiole  options  are  compiled.  There  is  no  capability 
to  select  notions  for  compilation. 


Ren  i i r emen t : r *> 

The  source  lanouaoe  will  contain  a simple  clearly  iden- 
tifiable nase  or  kernel  which  houses  all  the  power  of  the 
linauaqe.  To  the  extent  possible,  the  base  will  be 
minimal  with  each  feature  provjdina  a sinole  uniaue  capa- 
bility not  otherwise  duplicated  in  tne  base.  The  choice 
of  the  base  will  not  detract  from  the  efficiency,  safety, 
ir  understandabi 1 ity  of  the  lanouaae. 

Ihe  1 anauaqe  does  indeed  provide  a simple,  clearly  iden- 
tifiable pase  for  use.  Currently,  tne  larauaqe  ran  be 
easily  extended  to  increase  possible  usaoe.  As  it  now  ex- 
ists, such  facilities  as  Pit  manipulation,  overlay 
features,  floatino  noint  orocessinq,  recursion,  table  t a- 
cilit'*,  and  fixed  number  orocessjna  can  be  added  or 
deleted  from  the  lanouaae,  deoendina  uoon  thp  ohlect 
machine  environment. 


Requ i rement : 16 

*1'  ^ 

I.anauaqe  restrictions  which  are  dependent  orlv  on  the 
translator  and  not  on  the  ohlect  machine  will  he  speci- 
fy fied  explicitly  in  the  lanouaae  definition. 


t, 
* • 


* 

W 


Available  documentation  describina  compiler  limits  is 
precise  in  some  areas  and  vaaue  in  others.  For  example 
array  dimensions  and  identifier  lenatns  are  explicitly 
defined.  Mestlno  limits  ana  number  of  identifiers  were 
not . 

The  lanauaae  is  desiqned  for  use  on  a number  of  ouite 
different  machines.  Limits  are  nrobahlv  dependent  open 
the  machine  environment  in  at  least  some  cases. 


Requirement:  17 


* 


„ 

Lanouaqe  restrictions  which  are  inherently  aerendent  only 
on  the  object  environnent  will  not  be  built  into  the 
lanouaae  definition  or  any  translator. 


Tne  lanouaqe  satisfies  this  reaui  retien  t. . 


J.  EFFICIENT  OBJECT  REPRESENTATIONS  AND  MACHINE  PEPFNDEN- 

C1ES 


Requirement:  J1 

The  lanquaqe  and  its  translators  will  not  impose  run-time 
costs  for  unneeded  or  unused  oeneralitv.  They  will  be  ca- 
oable  of  oroducinq  efficient  code  for  all  rroqrams. 

p 

The  obiective  of  the  lanouaqe  development  has  been  to 
permit  latitude,  not  in  details  but  in  the  presence  or 
absence  of  major  features,  which  mav  or  mav  not  be  con- 
sidered wortn  havino  by  the  particular  instal lat ion.  A 
full  compiler  can  provide  all  features  hut  sunsets  are 
available.  F or  example,  a floatino  point  feature  would 
not  be  considered  useful  to  an  installation  lacEino 
floatino  point  nardware.  Therefore,  this  feature  can  be 
eliminated. 

Careful  use  of  the  lanouaae  will  produce  code  which  pro- 
vides almost  a one-  tor-one  correspondence  with  machine 
code . 


oeoui rement : JJ 

Any  optimizations  performed  by  the  translator  will  not 
cnaoqe  tne  effect  of  the  nroqram. 

In  so  far  as  we  Know,  translators  of  tne  lanouaae  do  not 
chanae  the  effect  of  the  oroaram. 


»eou i rement : J 1 

The  source  lanouaae  will  provide  encapsulated  access  to 
machine  dependent  hardware  facilities  includino  machine 
lanouaae  code  insertions. 

Tne  CODE  construct  provides  this  caoaoilitv. 


* 


Requirement:  J4 


It  will  ne  possible  within  the  source  lanquaae  to  soecifv 
the  oblect  presentation  ot  composite  data  structures. 
These  rtescr iDt i ons  will  be  optional  and  encanslated  and 
will  be  distinct  from  tne  loqical  description.  The  user 
will  be  able  to  soecifv  the  time/soace  trade-off  to  the 
translator.  If  not  specified,  the  oblect  representation 
will  be  optimal  as  determined  bv  the  translator. 


Soecifv  oolect  presentation T 

Soecitv  time/space  tradeoff V 


This  capability  is  somewhat  available  throuqh  use  of  the 
TABLF  construct.  Field  orders,  field  widths,  bit  pat- 
terns, and  field  structures  can  all  be  specified  within  a 
table  structure. 

There  is  no  mechanism  for  explicitly  snecifyino  tra- 
deoffs. however,  the  translators  do,  in  tact,  optimize 
data  man i pu 1 a t i ons  for  the  oblect  computer. 


Requirement:  J5 

The  oroorammer  will  be  able  to  specify  whether  calls  on  a 
routine  are  to  have  an  open  or  closed  implementation.  An 
open  and  closed  routine  of  the  same  description  will  have 
identical  semantics. 

The  open  implementation  for  machine  lanouaoe  insertions 
is  clearly  met  ny  the  lanquaqe.  Procedures  are  always 
defined  to  be  closed.  There  is  a macro  expansion  capabil- 
ity defined  within  the  lanouaoe,  but  it  does  not  com- 
pletely meet  tne  spec i f i cat i ons  . 


C0RAL66  F VALUATION  SUMMARY 


This  section  presents  a summary  of  the  findings  of  the 
evaluation  of  the  C0RAL66  lanouaoe.  Strenoths  and 
•nearnesses  of  the  language  are  presented.  Peou  i rement  s 
for  language  modi  f icat i on  necessary  to  meet  Don  reeds  and 
functions  are  addressed. 

CDPAL&b  has  a set  of  strenoths  that  specifically  meet  the 
requirements  of  the  "tinman".  These  include: 

Well  defined  syntax  --  Syntax  of  the  lanouaoe  cannot 
be  changed  - Few  key  words  are  reouired  to  defire  the 
lanouaqe  base  - No  word  ahbrev iat i ons  are  permitted  - 
Language  statements  are  tree  format. 

Strongly  typed  --  Identifiers  must  re  fully  declared 
before  use. 

Block  structured  --  Scope  of  identifiers  is  rlearlv 
discernable  - Pules  for  transfers  a mono  scones  are 
well  defined  and  clear. 

Feature  expandability  --  Inclusion  of  various  levels 
of  maior  features  depending  noon  facility  confiaura- 
t ion . 

Separate  comoile  capability  --  Proarams  mav  be  com- 
piled seoarately  and  linked  together  for  execution  at 
run-time. 

Machine  dependencies  excluded  from  lanouaoe  --  base 
lanquaoe  not  oriented  toward  anv  one  or  orouc  of 
mach i nes . 

Few  defaults  Permitted  --  Defaults  limited  to  capa- 
bilities included  within  specific  compiler. 

The  maior  weakness  identified  d urine  the  evaluation  was 
the  absence  of  lanouaoe  caoabilitv.  basically,  C0PAL66 
supports  a very  limited  subset  of  DOD  "TINMAN"  reauire- 
ment  s . 

Limited  control  structure  capability  --  Fxception 
handling  capability  very  limited  - Parallel  orocess- 
ino  not  explicitly  sunoorted  - Interrupt  handlino  not 
explicitly  defined  within  language. 

Small  sunset  of  operations  possible  --  No  provision 
for  whole  array  operations  - T /n  constructs  not 
available  - Power  sets  not  included  - Limited  Boolean 
caoaoi 1 i ty . 

Data  tyDe  definition  not.  supported  --  No  capability 
within  the  language  to  snecifv  new  data  tvnes. 

Fvaluatton  of  the  lanouaoe  did  not  identity  any  capabili- 
ties that  exceeded  " T I N M A L " requirements.  There  were  no 


r ■ ^ 

* special  operators  or  constructs  that  would  provide  a cro- 

h qrammer  with  capabilities  outside  the  scope  of  DUD  re* 

• quirements. 

Syntax  of  the  lanouaqe  dio  conform  to  the  rules  specified 
for  the  evaluation,  i.e.,  the  lanquaoe  syntax  would  not 
have  to  oe  noditied  to  eliminate  clashes  with  specifica- 
t i o n s presented  within  the  "TINMAN". 


In  aeneral,  CORALbb,  1 iVe  many  other  lancuaaes  of  Its 
type,  provides  a limited  number  of  constructs  which  can 
oe  used  to  solve  several  classes  of  aonl 1 cat i ons . The 
lamuaae  contained  no  unique  approaches  to  problem  solv- 
inq.  Rather,  the  syntax  follows  the  standard,  veil  tested 
methods.  The  lanouac7P  is  free  of  machine  dependent 
operations  and  can  he  transported  to  manv  different 
machines.  As  is  the  rase  with  other  lanouaaes,  specific 
application  oroorams  are  implementation  dependent  and  may 
require  manv  modifications  to  operate  rrorerlv  on  dif- 
ferent machines. 

Proorams  written  in  the  lanauaoe,  in  "any  cases,  tend  to 
he  difficult  to  follow,  due  to  the  comment  conventions 
employed.  Ma i nta i nah i 1 i f v is  one  of  the  maior  POD  opals. 


Modi f icat ion  of  C0RAL66  to  more  fullv  support  one  re- 
quirements is  possible.  Some  features,  such  as  tloatina 
point  capability,  division  with  remainder,  "NOT"  ana 
" M fl R " operators,  uniform  comment  notation,  and  typeri 
pointer  Kev  word  and  syntax  for  example,  car.  oe  easily 
included  within  the  lamuaae  at  relatively  little  ex- 
pense. other  features,  suen  as  expanded  arrav  and  record 
caoab i 1 i t i es , user  tvoe  definition,  I/O  device  defini- 
tions, Power  sets  of  enumeration,  and  expanded  exception 
handllna  for  example,  will  rrove  to  ne  much  *ore  costly, 
both  in  terms  of  time  and  money. 
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This  report  presents  an  evaluation  of  the  PASCAL  lanquaqe  with 
the  requirements  listed  in  the  "TINMAN".  ( DOD  Pequi  recent  s tor 
Hioh  Order  Computer  Proqramminq  Lanouaoes,  "TINMAN"  - 1 March, 

1976,  Section  IV).  For  purposes  of  comparison  PASCAL  is  con- 
sidered to  be  defined  nv: 

The  Proqramminq  Lanquaqe  Pascal 

There  are  7R  lanquaqe  requirements  listed  in  Section  4 of  the 
"Tinman".  This  report  compares  PASCAl  with  each  individual  re- 
quirement. A summary  of  the  dedree  to  which  the  lanouaqe  satis- 
fies each  requirement  is  presented. 

The  introductory  oaraoraph  of  each  "TINMAN"  requirement  is  in- 
cluded as  the  leadinq  section  for  each  requirement  evaluation. 

Symbols  Placed  beside  each  individual  requirement  irdicate  the 
deoree  to  which  the  lanouaqe  meets  the  requirement..  The  svmpols 
and  their  meaninus  are  as  follows: 

T - Total lv  meets  requirement 

P - Partially  meets  requirement 

F - Does  not  meet  requirement 

IJ  - Unknown  from  available  documentation 

A summary  of  the  evaluation  is  included  as  the  last  section  of 
thts  report.  werits  and  failures  of  the  lanauaqe  as  it  currently 
is  defined  are  discussed.  Also  discussed  are  the  potential 
lamuaie  modifications  that,  can  be  made  to  support  POD  "TINMAN" 
r equ i regents . 
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Requirement:  Al 


The  laniU’iae  will  be  typed . The  type  (or  mode)  of  all  variables, 
components  of  composite  data  structures,  expressions,  operations, 
and  parameters  will  be  determinable  at  compile-time  and  unalter- 
able at  run-time.  The  language  will  require  that  the  tyne  of 
each  variable,  and  component  of  composite  data  structures  bp  ex- 
plicitly specified  in  the  source  programs. 


■--T 


Every  variable  occurrina  in  a statement  must  oe  introducea  by  a 
variable  declaration  -which  associates  an  identifier  and  a data 
type  with  that  variable.  The  data  type  explicitly  or  implicitly 
defines  the  set  of  values  which  may  be  assumed  by  that  variable. 
A data  tvoe  in  PASCAT,  may  be  either  directly  described  in  the 
variable  declaration,  or  it  may  be  described  by  a type  identif- 
ier. Tn  the  latter  case  the  type  identifier  must  be  described  by 
an  explicit  type  declaration. 


Peauirement:  A2 


The  language  will  providp  data  tvres  tor  integer,  real  (floating 
point  and  f i xed-oo  int ) , Boolean,  and  character  and  -will  orovioe 
arrays  (i.e.,  composite  data  structures  with  indexable  comconents 
of  homogeneous  type)  and  records  (l.e.,  composite  data  structures 
with  labeled  comoonents  of  heteroaeneous  type). 


Integer  --- T 

F'loatino  point  ---T 

Fixedpoint  - - - E 

Boolean  T 

Character  ---T 

Arrays  T 

Records  T 


The  values  of  integers  are  the  inteqers  within  a ranae  which  are 
implementation  dependent. 


The  values  of  floating  point  real  quantities  are  a subset  of  real 


The  values  of  Poolean  variables  are  denoted  bv  the  keywords 
"true"  and  "false". 


There  are  two  character  types:  char  and  alfa.  The  set.  of  values 
of  the  type  char  is  the  character  set  available  on  the  printers 
of  a particular  installation.  Alfa  type  values  consist  of  se- 
quences of  characters  whose  lenath  is  defined  as  hPino  implempp.- 
tation  dependent  and  normally  infers  the  number  of  characters 
packed  oer  word  on  the  taruet  machine.  Individual  characters  are 
not  directly  accessible,  nut  alfa  quantities  can  ne  unpacked  from 
an  alfa  variable  to  a char  array  by  a standard  procedure. 


Roth  char  and  alfa  quantities  are  denoted  by  themselves  enclosed 
within  quotes. 


In  an  array  structure,  all  components  are  of  tne  same  type.  a 
component.  is  selected  bv  an  array  selector,  or  computable  index, 
whose  tyne  is  indicated  in  the  array  type  definition  and  which 
must  be  scalar.  It  is  usually  a nronrammer  defined  scalar  type, 
or  a suhranae  of  the  type  inteoer. 


In  a record  structure,  the  components  (called  fields)  are  not 
necessarily  of  tne  same  type.  in  order  that  the  type  of  a 
selected  component,  be  evident  from  me  source  nrooram  text  at 
comp i 1 e- t i me , a record  selector  does  not  contain  a computable 
value,  but  consists  of  an  identifier  uniouelv  denotina  the  con* 
oonent  to  ne  selected.  These  component  identifiers  are  defined 
in  the  record  definition. 


Fixed-Doint  data  typ®s  are  not  constituents  of  PASCAL  nor  can 
they  be  constructed  from  tne  primitive  data  tvr-es  unless  a 
subrame  of  the  tvop  real,  that  is  with  specified  urper  and  lower 
bounds,  is  considered  valid.  The  addition  of  fixed-point  data 
types  to  PASCAL  as  either  a primitive  data  tvoe  or  as  a subset  of 
the  real  data  tvoe  oy  incornoratjnq  a precision  clause  within  the 
subranqe  declaration  would  apoear  to  be  a s tr a i ob t f or  * ar d exten- 
sion to  the  lanquaoe. 


Requirement:  A 1 


The  source  lanquane  will  require  qiobal  (to  a scone)  specifica- 
tion of  tne  precision  for  floafinq  point  arithmetic  and  will  per- 
mit precision  snec 1 f lcat  ion  for  individual  variables.  The 
specification  will  he  interpreted  as  the  maximum  precision  re- 
quired bv  the  oroqram  loqic  and  the  minimum  precision  to  be  sup- 
ported oy  tne  oblect  code. 


Tr 


P ASC  A [,  does  not  support  the  concept  of  precision  sneci  t i rat  i on  of 
floating  point  variables  either  at  a block  structure  level  or  on 
an  individual  variable  basis.  It  would  be  a straiahtforward  pro- 
position to  extend  the  language  to  require  that  each  block  in 
which  floating  point  variables  are  declared  include  a declaration 
of  the  precision  required  for  arithmetic  operations  performed 
within  tnat  block  and  for  the  actual  data  representations  of  lo- 
cal floatinq  point  variables.  However,  it  is  anticipated  that  to 
allow  unique  precision  soeci f i cat i ons  for  each  variable  would 
result  in  possibly  inefficient  object  code  and  an  excessive 
comp  i le-t  irre  burden  resultino  from  increased  subtype  cneckina  and 
the  inclusion  of  object  code  for  data  representation  conversion. 
Alternatively  the  precision  could  be  utilized  by  the  compiler 
only  to  determine  if  the  tarqet  machine  were  capable  of  surrort- 
ino  the  specified  precision. 


Requ irement : A4 


Fixed-point  numbers  will  be  treated  as  exact  quantities  which 
have  a ranoe  and  fractional  step  size  which  are  determined  by  the 
user  at  comp i l e-t ime . Scale  factor  management  will  be  done  by 
the  combiler. 


N / A 


Since  PA SC Ah  does  not  include  a real  fixed-point  data  type,  ei- 
ther as  a primitive  or  the  ability  to  qenerate  it  from  its  Drim- 
itives,  then  the  question  of  fixed-point  ranoe  and  resolution  are 
not  aoolicable.  However,  if  the  extension  concernirq  the  intro- 
duction of  real  fixed-point  data  tyres  described  in  the  response 
to  Section  A 2 were  implemented  as  a primitive  data  type,  then  the 
resolution  and  lower  and  upper  bounos  could  be  specified  as  an 
extension  to  t.ne  subrange  clause.  The  information  within  such  a 
clause  would  provide  all  the  attributes  necessary  for  the  com- 
piler to  handle  scale  manage me nt  and  produce  oniect  code  for 
bound  checking,  if  desired. 


Requirement:  AS 


Character  sets  will  oe  treated  as  any  other  enumeration  type. 


P + 


The  internal  representation  of  PASCAL  char  and  alfa  tyre  data 
items  is  not  define  1 within  the  lanquaae  and  would  most  probably 
be  fixed  for  anv  liven  implementation.  However,  the  ability  to 
define  scalar  tyoes  will  allow  anv  desired  coallation  seouence 
for  an  alphabet.  As  a result  several  alphabets,  includino  ASCII 
and  RRCDIC,  could  be  defined,  thus,  manoinq  from  one  to  another 
would  oe  a trivial  task.  The  ASCII  and  RRCPIC  alohabets  are  not 
predefined  within  the  lamuaqe  spec  i f teat  ion , thus,  requirinq 
each  user  to  declare  then  accordinq  to  the  definable  scalar  for- 
mat . 


Requirement:  Aft 


The  lanquaae  will  require  user  specification  of  the  number  of  di- 
mensions, the  ranqe  of  subscript  values  for  each  dimension,  and 
the  tyoe  of  each  array.  The  number  of  dimensions,  the  type  of 
lower  subscript  pound  will  be  determinable  at  comp i 1 e-t in e . The 
upper  subscript  pound  will  be  deter minable  at  entry  to  the  array 
allocation  scone. 


P + 


An  array  type  is  a structure  ronsistim  of  a fixed  number  of  com- 
ponents which  are  all  ot  the  same  type,  referred  to  as  the  com- 
ponent type.  The  elements  of  the  array  are  desionated  by  in- 
dices, values  oelonuinq  to  the  so-called  index  type.  The  array 
type  definition  specifies  noth  the  component  type  and  the  index 
tyoe.  Both  lower  and  upper  bounds  are  normally  specified  at 
compile-time.  However,  utilization  of  the  class  tyne  definition 
in  conlunction  with  standard  procedure  allocation  provides  the 
ability  to  allocate  the  array  at  scope  entry.  This  is  done 
dynamically,  which  is  In  conflict  with  the  "tinman"  renuirement 
Put  the  class  tyoe  definition  requires  that  the  maximum,  array 
size  be  explicitly  specified  at  comp i 1 e-t ime . It  is  our  opinion 
that  this  requirement  satisfies  the  intent  of  the  "Tinman"  re- 
quirement . 


Reaurement:  A7 


The  lanquaqe  will  permit  records  to  have  alternative  structures, 
each  of  which  is  fixed  at  comp  i le-t  ime . The  nam.e  and  type  of 
each  record  component  will  be  specified  by  the  user  at  comoile- 
t ime . 


(’  + 


A recdrd  is  a structure  consisting  ot  a fixed  number  of  com- 
ponents, possibly  of  different  types.  Tne  record  tvpe  definition 
specifies  for  each  component,  called  a field,  its  tvpe  ard  the 
identifier  whicn  denotes  it.  A record  type  may  have  one  or  more 
alternative  structures,  referred  to  as  variants,  as  specified  by 
the  "TINMAN".  However,  at  a niven  time,  the  specific  variant  is 
selected  by  the  value  of  a simle  fixed  field  of  the  record,  re- 
ferred to  as  tne  taq  field.  'I  his  is  in  conflict  with  the  "TIN- 
MAN" requirement  which  requires  that  alternative  structures  be 
selected  nv  a general  Boolean  expression.  The  extension  of  the 
language  to  satisfy  this  suhregui rerrent  is  consinered  to  be  ex- 
tensive since  it  would  imply  a totally  different  selection 
mechanism  than  the  currently  specified  taa  field. 


Requirement:  Rl 


Assignment  and  reference  operation  will  be  automat i ca 1 1 v defined 
for  all  data  types  which  do  not  manaoe  their  data  storaae.  The 
assignment  operation  will  permit  any  value  of  a oiven  type  to  be 
assioned  to  a variable,  array  or  record  component  of  that  type  or 
a union  type  containing  that  type.  Reference  will  retrieve  the 
last  assigned  value. 


P + 


The  PASCAL  assignment  statement  will  allow  a variable  of  any 
given  tyne,  with  the  exception  of  class  and  file  types  to  be  as- 
signed to  an  expression  of  the  identical  type.  TMjs,  an  entire 
array  can  be  equated  to  an  equivalent  array,  an  entire  record  to 
an  equivalent  record , or  a component  of  a record  to  a similar 
equivalent  component  or  primitive  variable  of  identical  tyre. 
There  are  two  relaxations  to  this  general  rule  of  fyne  consisten- 
cy : 


1)  Where  the  tyoe  ot  the  dependent  variable  is  real  and  the  . 
type  of  the  expression  is  Integer  or  a subrange  thereof. 


71  Where  the  tvne  ot  the  expression  is  a subranoe  ot  the  in- 
dependent variable. 


These  tyre  checking  relaxations  could  readily  be  deleted  from  any 
given  implementation,  however,  the  ability  to  assion  file  and 
class  tyne  data  items  would  oe  considered  a ma  lor  impact  and 
would  require  a detailed  analvsis  to  determine  any  undesirable 
side  effects  or  conflicts. 


Requirement:  R2 


The  source  lanquaqe  will  have  a built-in  operation  which  can  be 
used  to  compare  any  two  data  objects  (reqardless  of  tvne)  tor 
i dent i t v . 


-P  + 


The  PASCAL  lanquaqe  identity  operators  tor  equality  (=)  and  ine- 
quality (4)  may  be  used  with  ooerands  of  any  type  with  the  excep- 
tion of  class  and  file  tvoes,  the  result  is  always  type  Boolean. 


To  include  the  operand  types  class  and  file  would  be  considered  a 
major  impact  for  the  same  reasons  as  described  in  the  response  to 
Section  Bl  of  this  report. 


Requirement:  B3 


Relational  operations  will  be  automat  ica 1 1 v defined  for  numeric 
data  and  all  types  defined  py  enumeration. 


Pi 


The  relational  operators  defined  for  PASCAL  are  as  follows: 


= 4 

< > 


The  identity  operators  may  be  used  with  any  data  type  with 
the  exceptions  of  those  noted  in  Section  B2.  The  relative  opera- 
tors (<,>»•$, ^)  may  oe  utilized  with  any  scalar  or  subranae  tyne. 
The  scalar  types  include  the  predefined  items,  inteoer,  real. 
Boolean,  char  and  alfa,  and  those  defined  by  enumeration.  It 
should  be  noted  here  that  the  semantics  of  the  relative  operators 
within  the  alfa  context  are  not  obvious  and  are  defined  below. 


If  X and  Y are  alfa  identifiers,  the  value  of  which  consist  of 
sequences  of  n characters,  where  n is  an  implementation  dependent 
parameter,  (see  Section  A2)  then: 


x < Y if  Xi=Yi  for  1 < i <k - 1 and  Xk<Yk 


l ' 

x > Y if  xi  = Yi  tor  Ki<k-1  and  Xk>Yk 


Requirement:  (‘4 


The  built-in  arithmetic  operations  will  include:  addition,  sub- 
traction, multiplication,  division  (with  a real  result),  exponen- 
tiation, inteoer  division  (with  inteoer  or  fixed-noirt  arauments 
and  remainder),  and  neoation. 

— -Pt 


The  arithmetic  operators  of  PASCAL  are  defined  as  follows: 


* 

multiplication 

/ 

division 

d i v 

division 

with 

truncat ion 

mod 

m mod  n — m 

- ( ( m 

div  n ) *n  ) 

+ 

addition 

or  identity 

- 

subtraction  or 

inversion 

The  mu  1 1 i p 1 icat ion  (*),  division  (/),  addition  ( + ),  and  subtrac- 
tion (-)  operators  permit  the  operands  to  be  real,  inteqer,  or 
mixed.  The  result  for  multiplication,  addition,  and  subtraction 
is  inteoer  only  if  both  operands  are  inteoer,  else  it  is  real. 
The  result  for  the  division  operator  is  always  real.  The  div  and 
mod  operators  mav  be  utilized  with  inteoer  operands  only,  yield- 
ing inteqer  results  of  a truncated  inteoer  division  and 
remainder,  respectively.  There  is  no  exponentiation  operator. 
To  add  that  feature  would  be  relatively  minor  if  a decision  con- 
cerning tne  semantics  and  result  type  could  be  resolved.  For  ex- 
ample, the  expression  A*  * x ** Y if  evaluated  with  a conventional 
left  to  rioht  precedence  is  equivalent  to  a**(X+Y)  which  some 
would  argue,  is  not  what  was  intended.  If  evaluated  with  a rioht 
to  left  orecendence,  the  result  is  equivalent  to  A*t*(x**Y). 
This  results  in  the  relatively  complex  semantic  rules  that  ir  the 
absence  of  parenthesis  expression  operators  are  evaluated  accord- 
i no  to  precedence  and  left  to  rioht  with  the  exception  of  the  ex- 
ponentiation operator  which  is  evaluated  rioht  to  left. 


In  addition,  the  result  type  of  an  exponentiation  operation,  when 
both  operands  are  inteoer  also  causes  considerable  confusion  un- 
less clearly  defined.  Finally,  the  possibility  of  complex 
results  introduces  a further  confusion  factor.  The  desioner(s) 


f- 
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* Of  PA SC A!i  were  perhaps  wise  In  omltttnq  the  exponentiation  opera- 
tor fron  the  arithmetic  operator  set. 


Requirement:  R s 


Arithmetic  and  assiqnment  operations  on  data  which  are  within  the 
rame  specifications  of  the  proor am  will  never  truncate  the  mos  t 
siqnificant  dibits  of  a numeric  quantity.  Truncation  and  round- 
ina  will  ne  on  the  least  siqnificant  diaits  and  will  never  he  im- 
plicit. for  inteoers  and  fixed- point  numbers.  Implicit  roundinn 
beyond  the  specified  precision  will  be  allowed  tor  floatinn  point 
numbers . 


P 


No  truncation  of  most  siqnificant  dibits  ---U 

No  implicit  truncation  or  roundinq  for  tixed-ooint  and  inteoer 
operands  T 

Implicit  roundinq  oeyond  specified  precision  ---n/a 


The  source  material  used  for  this  report  was  addressed  to  the 
PASCAL  lanquaqe  definition,  not  a compiler  implementation,  thus, 
it  was  not  possible  to  determine  if  most  siqnificant  dtqit  trun- 
cation would  ever  occur.  Statinq  that  it  should  never  occur  is 
an  incomplete  specification,  since  there  are  obvious  instances 
where  it  could  occur,  the  most  common,  perhaps,  is  the  assiqnment 
of  a floatinn  point  expression  to  an  intener  or  fixed-point 
operand.  Since  the  latter  will  aenerally  have  a more  restricted 
ranae  then  should  that  ranee  be  exceeded  what  acMon  is  to  be 
taKen?  In  most  environments  the  choice  is  to  either  ionore  the 
discreoancv  resulting  in  what  is  essentially  modulus  arithmetic 
or  to  abort  the  execution  of  the  oronram  and  return  control  to 
the  system  executive.  It  would  certainly  be  feasible  and, 
perhaps,  desirable  to  the  HOL  proiect  to  provide  the  source 
lanauaqe  with  a mechanism  to  specify  those  actions  such  that  the 
user  would  retain  control,  if  desired.  This  could  he  accom- 
plished py  optionally  specifyino  at  the  entrance  to  each  bloc*  an 
identifyim  procedure  label  which  would  be  executed  if  overflow 
occurs.  /U  t.  n i n that  procedure,  the  user  would  determine  the  need 
to  either  abort  nrooram  execution  or  to  continue. 


ImDlicit  truncation  cannot  occur  within  PASCAL  assianments  since 
a real  expression  cannot  ne  assioned  to  an  inteoer  operand.  In 
addition,  within  an  expression,  mixed  mode  operations  always 
result  in  a real  value.  Explicit  truncation  of  real  expressions 
can  be  achieved  by  use  of  the  standard  function,  trunc. 


Since  floatinn  noint  precision  is  not  an  attribute  of  the 


»tw*Yfr  •'  Vi-  r* 
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language,  illicit  rounding  beyond  a specified  precision  is  not 
applicable.  however,  if  precision  specification  were  included  as 
described  in  Section  A3  then  it  is  anticipated  that  a real  ex- 
pression would  be  evaluated  within  the  maximum  precision  support- 
ed by  the  taroet  irachine,  only  the  operation  of  assignment  would 
round  the  result  to  the  specified  precision. 


Requirement: 


The  built-in  boolean  operations  will  include  "AND",  "OP",  "NOT" 
and  " N OR".  The  operations  on  scalars  will  be  evaluated  in  short 
circuit  ^ode. 


P 


The  built-in  boolean  operations  of  PASCAL  are  as  follows: 


/\(  logical  "AND") 

VC  loci  cal  "OP") 
~1(  logical  "NOT") 


The  operation  "NOR"  is  not  explicitly  available  within  the 
language.  It  is  anticipated  that  it  could  be  incorporated  with  a 
minimum  effort.  However,  purists  mav  argue  that  it  is  not  only 
unnecessary  but  undesirable  since  both  "NOR"  and  "AMD"  can  be 
represented  by  use  of  the  "not"  operator  applied  to  a subexpres- 
sion in  parentheses. 


The  language  definition  does  not  specify  the  semantics  of  short- 
circuit  evaluation,  however,  any  implementation  could  of  course, 
employ  short-circuit  evaluation  techniques. 


Requirement:  P7 


The  source  lanouaqe  will  permit  scalar  operations  and  assignment 
on  conformable  arrays  and  will  permit  data  transfers  between 
records  or  arrays  of  identical  logical  structure. 


T 


Scalar  operations  on  arrays 


T(U) 


type 


fcss  i anment  between  records  and  arrays  of  comfortable 
T 


It  is  clear  from  the  PASCAL  lanquaqe  definition  that,  assignments 
between  records  and  arrays  of  conformable  type  are  valid.  In  ad- 
dition, entire  variables  reoresentinq  arrays  can  apparently  be 
operands  of  expressions.  However,  the  semantics  of  such  opera- 
tions is  undefined,  thus,  multiplication  of  arrays  could  imply 
matrix  multiplication.  The  obvious  solution  to  this  would  be  to 
include  explicit  semantic  definitions  within  the  lannuaqe  spec  i f - 
icat ions . 


Requirement:  b 1 0 


The  base  lannuaae  will  provide  operations  allowing  nroararr.s  to 
interact  with  files,  channel's.,,  or  devices  (includino  terminals). 
These  operations  will  permit  sending  and  receivina  both  data  and 
control  information,  will  enable  broqrams  to  avnam i ca 1 1 y assion 
and  reassion  I/O  devices,  will  provide  user  control  for  exception 
conditions,  and  will  not  be  installation  dependent. 


p + 


A file  structure  in  PASCAh  is  a seauence  of  components  of  the 
same  tyoe.  A natural  orderina  of  the  components  is  defined 
through  the  sequence.  At  any  instant,  only  one  component  is 
directly  accessible.  The  other  components  are  made  accessible 
throuqh  the  standard  file  positioninq  procedures:  nut,  qet  and 
reset.  At  any  aiven  time,  a tile  is  in  one  of  three  modes  called 
inout,  output  and  neutral.  Accordim  to  the  mode,  a file  can  be 
read  sequentially  or  it  can  be  written  to  by  aonendtnq  components 
to  the  existino  sequence  of  components.  File  rositionina  pro- 
cedures may  determine  the  current  mode.  The  tile  tyne  definition 
does  not  determine  the  number  of  components,  and  this  number  is 
variable  durinq  the  execution  of  the  program.  The  components  of 
a file  mav  be  a simpLe  primitive  data  type  (i.e.,  inteaer)  or  may 
be  complex  structures,  the  specific  form  of  the  structures  beiro 
defined  by  a record  definition.  Two  standard  tile  variables  can 
be  considered  as  predeclared  for  all  implementations  as: 

input,  output:  file  of  char 


The  tile  input  is  restricted  to  input  mode  (readinq  only),  and 
the  file  output  is  restricted  to  output  mode  (writing  only).  A 
PASCAL  program  should  be  regarded  as  a procedure  with  these  two 
variables  as  formal  parameters.  The  corresponding  actual  parame- 
ters are  expected  either  to  re  standard  inout  and  output  devices 
of  the  tarqet  computer  installation  or  to  be  assignable  by  the 
system  commands  of  the  target  computer.  As  a result,  it  would 
aooear  that  files  would  not  normally  be  dynamically  assignable, 
however,  additional  standard  procedures  could  be  added  to  a aiven 
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implementation  to  provide  a dynamic  r eass  i undent  capability, 


The  standard  tile  positlonina  ororeriures  are  drfineo  relow: 


d u t ( I' ) 


Advances  the  tile  pointer  of  tile  F to  the  next  file 
component.  It  is  onlv  aprlicanle  if  the  file  is  in  ei- 
ther the  outout  or  neutral  node.  ‘Her  execution,  the 
file  is  in  the  output  mode. 


qet  (F) 


Advances  the  file  pointer  of  tile  t to  the  next  file 
component.  it  is  onlv  aonlicaole  it  the  file  is  in  ei- 
ther tne  input  or  neutral  mode.  If  there  dors  not  exist 
a next  tile  component,  the  end  of  file  condition  ar- 
ises, the  value  of  the  variable  denoted  by  the  tile 
pointer  becomes  undefined,  and  tne  file  is  rut  into  the 
neutral  mode. 


reset  CF)  The  tile  pointer  o*  file  F is  reset  to  its 
and  the  file  is  put  into  the  neutral  mooe. 


heci  inn  i no  , 


N.K.  Initially  a file  variable  is  in  the  neutral  mode. 


In  addition  to  tne  file  nositiooinq  procedures,  a further  stan- 
dard function  is  available  to  determine  the  end-of-file  status  of 
a file.  The  function  is  eot  with  the  file  variable  as  an  argu- 
ment. The  function  type  Is  boolean  which  when  true,  indicates  an 
end-of-file  status.  Any  otner  conditions,  such  as  data  transfer 
error,  are  not  available  as  standard  functions  but  could  be  In- 
cluded in  any  qiven  implementation  at  an  anticipated  low  to 
moderate  cost. 


Feouirement:  Rll 


The  lanquaoe  will  provide  operations  on  data  types  as  power  sets 
of  enumeration  types  (Section  F6).  The  operations  will  include 
union  intersection,  difference,  complement,  and  an  element  predi- 
cate. 


p 


A PASCAL  oowerset  tvoe  defines  a ranee  nf  values  as  the  powerset 
of  another  scalar  type,  the  so-called  base  tyre  operators  appli- 
cable to  all  power  set  types  are: 


union 


■ r 


w<*tu i renent : Cl 


Side  effects  which  are  dependent  on  the  evaluation  order  amona 
the  (inuTpnts  of  an  expression  will  oe  evaluated  left  to  riaht. 


«--T 


The  source  documentation  specifies  that  sequences  of  operators  of 
the  saTe  precedence  level  are  executed  from  left  to  right.  The 
rules  of  precedence  are  reflected  hy  the  specified  syrtax  defini- 
tion. 


Requirement:  C? 


nihich  oarts  of  an  expression  constitute  tne  operands  to  each 
operation  within  that  expression  should  ne  obvious  to  the  reader. 
There  will  he  few  levels  of  operator  hierarchy  and  they  will  he 
widely  recognised. 


>--T 


Expressions  are  constructs  denoting  rules  for  obtaining  values  of 
variables  and  generating  new  values  by  tne  application  of  opera- 
tors. Expressions  consist  of  operands  (i.e.,  varianles,  con- 
stants and  functions!  and  operators. 


The  rules  of  composition  snecifv  operator  orecedences  according 
to  four  classes  of  operators.  The  Boolean  negation  operator  (1 
has  the  hiahest,  mu  1 1 iolvi na  operators  ( * , / , di v ,mod  , “ ) , then  the 
so-called  adding  operators  and  finally,  with  the  lowest 
precedence,  the  relational  operators  ( = , ^ ,<,>,.$, ^) . These  pre- 
cedence levels  are  fixed  and  cannot  he  altered  by  the  user  as  re- 
quired ov  the  "TIMMAN”.  In  addition,  conventional  explicit 
parenthetical  pairs  can  he  included  within  expressions,  to  any 
desired  level,  to  soecifv  the  intended  evaluation  seouence  or  to 
ensure  the  required  evaluation  order  of  operators  of  the  same 
precedence  Level. 


Requirement:  (.  T 


Expressions  of  a jiven  tvop  will  he  permitted  anywhere  In  source 
programs  where  noth  constants  and  references  to  variables  of  that 
type  are  allowed. 


Ppqu  1 ref ent : n 


Constant  expressions  will  he  allowed  in  proqrams  anywhere  con- 
stants are  allowed,  and  constants  will  be  evaluated  before  run- 
tine. 


•--F 


PASCAL  does  not  support  the  concent  of  constant  comp i 1 e-t i me  ex- 
pressions either  in  the  form  of  literal  or  parameterized  con- 
stants. Parameter ized  constants  are  definable  and  mav  appear  at 
any  noint  where  a literal  constant  is  specified.  Parameterized 
constants  are  qenerallv  favored,  since  they  allow  a sinale  as- 
sidnment  of  a co-np i 1 e-t i me  identifier  to  a value  which  mav  subse- 
quently oe  utilized  by  numerous  references.  Coupled  with  the  ca- 
pability of  compile-time  expression  evaluation,  compile-time 
identifiers  may  he  functions  of  other  similar  identifiers,  tnus 
ninimizim  pronrammer  errors  and  providinq  a readilv  maintain- 
able environment.  The  addition  of  sucn  a capability  to  PASCAL 
would  oe  considered  a moderate  effort. 


Peouirement:  Cb 


There  will  he  a consistent  set.  of  rules  applicable  to  all  parame- 
ters, wnether  tney  be  for  procedures,  types,  exception  hardline, 
parallel  processes,  declaration,  or  built-in  operators.  There 
will  oe  no  special  operations  (e.p.,  array  substrnctur ina)  appli- 
cable only  to  parameters. 


. - _ T 


Consistency  has  been  achieved  for  parameter  hanolina  within  PAS- 
CAL, orimiarlv  inherited  from  its  predecessor  ALGOf  60.  Identif- 
ier references,  oe  tney  actual  or  formal,  are  fully  typed  to  en- 
sure that  consistency. 


Peouirement:  C6 


Formal  and  actual  oarameters  will  always  aoree  in  type.  The 
number  of  dimensions  for  array  parameters  will  be  determinable  at. 


compile-time.  The  size  and  sub  script  r anqe  for  array  parameters 
need  not  be  determinable  at  compile-time  out  can  be  passed  as  a 
part  of  the  parameter. 
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will 
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arravs  is 
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Actual  parameters  are,  of  course,  defined  by  the  normal  data  oe- 
claration  constructs.  formal  parameters  are  declared,  or  more 
correctly  specified,  by  appending  the  appropriate  clause  to  the 
formal  parameter  synonym.  There  exist  tour  clauses  to  specify 
the  four  Kinds  of  parameters:  variable,  constant,  procedure,  and 
f unct i on  . 


In  the  case  of  var iab le-Darameter s the  actual  parameter  must  be  a 
variable.  If  it  is  a variable  denotina  a component  of  a struc- 
tured variable,  the  selector  is  evaluated  prior  to  execution  of 
the  procedure.  If  the  parameter  is  a constant  parameter,  the 
corresDonlina  actual  parameter  must  be  an  expression.  If  the 
parameter  is  a procedure  or  function,  the  corresponding  actual 
parameter  must  be  a procedure  or  function  identifier,  respective- 
ly. Actual  to  formal  parameter  correspondence  Is  ach i e ved  fy  the 
ordinal  oositions  of  the  parameters  in  the  lists  of  actual  and 
formal  parameters  and  bounds. 


The  ranK  of  arravs  are  not  specified  by  the  formal  parameter  de- 
clarations and,  thus,  must  be  passed  as  a part  of  the  actual 
parameter  uoon  invocation  of  the  procedure. 


Requirement:  Cl 


There  will  be  only  four  classes  of  formal  parameters.  for  data 
there  will  be  those  actino  as  constants  represent  inn  the  actual 
parameter  value  at  the  time  of  call  and  those  which  rename  the 
actual  Parameter  which  must  be  a variable.  In  addition,  there 
will  be  a formal  oarameter  class  for  soecifyino  the  control  ac- 
tion when  exceotion  conditions  occur  and  a class  for  procedure 
parameters . 


- Call  uy  value  parameters  ---T 


Call  oy  value  parameters  ---T 
Call  oy  nai>e  parameters  ---T 
Fxception  handlina  parameters  ---u 
Procedure  identifier  parameters  ---T 


The  types  of  proceiure  parameters  available  to  PASCAL  are  defined 
in  Section  C6  of  this  report.  They  are:  constant,  variable,  pro- 
cedure, and  function.  Constant  and  variable  parameters  are 
eauivalent  to  "call  by  value"  and  "call  by  name"  parameters, 
respectively.  Tne  procedure  identifier  parameter  allows  pro- 
cedures to  be  passed  as  actual  parameters  to  other  procedures  as 
mandated  by  the  "TINMAN". 


It  is  unclear  from  the  source  documentation  as  to  the  availabili- 
ty of  exception  handlina  parameters,  most  commonly  encountered, 
in  the  form  of  labels. 


Pequ i r ement : Cfi 


Specification  of  the  type,  ramie,  precision,  dimension,  scale, 
and  format  of  parameters  will  be  optional  in  the  procedure  de- 
claration. None  of  them  will  be  alterable  at  run-time. 


4 

L. 


<’  i 


Specified  attributes  optional  ---F 

Attributes  unalterable  at  run-time  ---T 


All  procedure  formal  parameters  are  fully  typed  within  the  pro- 
cedure headim  to  ensure  consistency  of  tvoe  with  the  actual 
parameters  encountered  at  procedure  invocation.  Tf  those  formal 
parameter  attributes  were  optional,  it  is  difficult  to  envision 
how  type  consistency  could  re  effectively  manaaed.  Tn  fact,  this 
requirement  appears  to  be  in  conflict  with  much  of  the  "TINMAN" 
since  overall  data  tvoe ' cons i stency  is  one  of  the  maior  conven- 
tions dictated. 


Requirement:  C9 


i 


There  will  he  provisions  for  variable  numpers  of  arnuments 


but 


• in  such  casps,  all  but  a constant  number  of  them  trust  be  of  the 
same  type.  Whether  a routine  can  have  a variable  number  of  argu- 
ments must  be  determinable  from  its  description  and  the  number  of 
arguments  for  any  call  will  be  determinable  at  comoiie-time  . 


PASCAL  procedure  parameters  are  limited  to  the  fixed  number 
specified  by  the  declaration.  bach  procedure  invocation  mgst,  of 
course,  include  the  same  number  of  actual  parameters. 


The  concent  of  variaole  numbers  of  arguments  to  procedures  is, 
thus,  somewhat  foreign  to  this  language.  However,  within  the 
specified  restraints,  it  would  appear  to  be  a realistic  require- 
ment. The  impact  of  including  the  capability  within  a given 
language  implementation  would  be  moderate  to  major. 


Reou i rement : PI 


The  user  will  have  the  ability  to  associate  constant  values  on 
any  tyne  with  identifiers. 


The  constant  definition  facility  provided  enables  an  identifier 
to  be  a synonym  for  n constant.  The  constant  may  he  a signed  or 
unsigned  real,  or  integer  number,  a character  strina,  a user  de- 
fined Identifier,  or  the  undefined  pointer  constant  nil. 


Reou i rement : P? 


The  language  will  provide  a syntax  and  a consistent  interpreta- 
tion for  literals  of  built-in  data  types.  Numeric  literals  will 
have  the  samp  value  (within  the  specified  precision!  in  noth  pro- 
grams and  data  (incut,  or  output). 


T , N / A 


Consistent  literal  svntax  and  interpretation 


Equivalent  literal  values  for  programs  and  data 
- — N / A 


There’ Is  a sinole  syntactic  definition  „and  hence  implied  in- 
terpretation for  references  to  all  literals  thus  nrovidino  a con- 
sistent notation. 


The  r ecu  i re-rent  for  eiuivalent  literal  value  representation  in 
both  proqram  and  data  input  is  considered  out  of  scone  of  toe 
lanauaoe  definition  which  does  not  address  the  run-time  environ- 
ment . 


Requirement:  P 3 


The  lanquane  will  permit  the  user  to  specify  tne  initial  values 
of  individual  variables  will  be  initialized  at.  the  time  of  their 
aDnarent  allocation  (i.e.,  at.  entry  to  allocation  scone)  . There 
will  be  no  default  Initial  values. 


PASCAL  does  not  supDort  the  concept  of  variable  data  initializa- 
tion. The  value  of  variables  of  entry  of  allocation  scone  is  un- 
defined. Since,  for  efficient  memory  manaqement  it  is  normal  for 
non  inter f er ina  proqram  blocks  to  share  data  scace,  initialization 
cannot  occur  at  eitner  compile  or  load  time  and  must  become  a 
dynamic  run-time  feature,  this  is  in  partial  conflict  with  the 
" T I A ’J " reau i remen t . 


The  extensions  to  tne  lanouaqe  to  accomodate  initialization  would 
be  minor  but  the  impact  on  data  rr.ananement  to  fully  satisfy  the 
requirement  would  oe  moderate. 


Requirement:  D4 


The  source  lanouaqe  will  require  its  users  to  specify,  individu- 
ally, the  ranoe  of  all  numeric  variables  and  the  steo  size  for 
fixed-ooint  variables.  The  ranoe  specifications  will  be  inter- 
preted as  the  maximal  ranoe  of  values  which  will  be  assianed  to  a 
variable  and  the  minimal  ranoe  which  must  be  supported  by  the  ob- 
lect  code.  banqe  and  steo  size  specifications  will  not  be  inter- 
preted as  definino  new  types. 


Numer ic 
F 


ranoe 


srec i f 1 cat  ion 


mandatory 


p 


Fixed  point  step  size  specifications  mandatory 

N / A 

Range  and  step  size  specifications  do  not  define  a new  data  type 

p 


PASCAL  does  support  the  concept  of  ranqe  specification  for  both 
the  predefined  scalar  quantities  (integer,  etc.)  and  those  data 
types  defined  by  enunerat i on . However*  contrary  to  the  "T1NVAN" 
requirement  such  ranqe  specifications  are  optional  and  each  ranoe 
specification  is  considered  a unique  data  type.  To  modify  the 
language  to  require  that  all  numeric  variables  require  a ranoe 
specification  would  require  minimal  effort,  out  the  conceptual 
change  of  not  considerino  such  suhrame  types  to  op  unique  would 
be  malor,  since  it  would  cnarne  the  total  structure  of  the 
1 anqua  qe . 


f Perhaps,  the  obiect  of  the  requirement  is  to  allow  assignments, 

etc.,  between  variously  ranged  variables  of  tne  same  general 
class  without  violating  the  stringent  type  checking  rules  speci- 
fied within  the  "TINMAN".  As  Previously  described  within  this 
report,  PASCAL  conveniently  skirts  this  issue  by  relaxing  tyne 
checking  between  scalars  and  subranges  tnereof.  If  this  approach 
is  considered  acceptable,  the  overall  impact  would  ne  minimal. 


Since  fixed-point  variables  are  not  supported  bv  PASCAL,  the 
question  of  step  size  is  not  applicable.  However,  if  fixed-point 
variables  were  introduced,  it  would  appear  that  for  total  con- 
sistency and  for  little  additional  effort,  tne  step  size  attri- 
bute could  be  introduced. 


A.. 


Requirement:  ns 


The  ranqe  of  values  which  can  be  associated  with  a variable,  ar- 
ray or  record  component  will  be  any  built  in  tvne,  any  defined 
type  or  a contiguous  subsequence  of  any  enumeration  type. 


— r 


PASCAL  data  declarations  are  recursive  in  that  element,  values  of 
all  identifier  types  can  themselves  be  tyoed  identifiers.  This 
permits  arrays  to  be  components  of  records  or  arravs  ano  permits 
records  to  be  components  of  records  or  arrays.  An  element  value 
may  be  a contiguous  subsequence  of  any  enumeration  type  if  that 
suoseouence  is  defined  as  a subrange  tyoe  of  tne  entire  sequence. 


Requ i rement : hfe 


The  lanquaqe  wi"ll  provide  a pointer  mechanism  which  can  be  used 
to  build  data  with  shared  and  for  recursive  substructure.  The 
pointer  property  will  only  affect  the  use  of  variables  (includina 
array  and  record  components')  of  same  data  types.  Pointer  vari- 
ables will  he  as  safe  in  their  use  as  are  any  other  variables. 


Pa 

Pointer  mechanism(s)  available 

— T 

Shared  data  structures 

T 

Recursive  data  structures 

— T 

Pointer  property  type  is  bound 

T 

to  data 

structure 

type 


Pointer  property  will  be  only  for  variables  of  composite  corr- 
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Type  and  access  restricted  pointers  ---T 


PASCAL  'class'  variables  which  are  dynamically  assioned  ov  refer- 
ence to  the  standard  procedure  allocation  may  only  be  referenced 
by  pointer  type  variables.  Class  variables  may  be  of  any  type, 
either  user  defined  or  predefined  scalar,  which  is  in  conflict 
with  the  "TINMAN"  reouirement  which  dictates  tnat  only  composite 
data  structures  may  be  referenced  by  pointers.  A pointer  is 
bound  to  a qiven  'class'  variable  by  an  appropriate  declaration 
and,  tnus,  ensures  type  checkinq  for  pointer  variables  in  a 
fashion  compatible  with  nonnointer  variables.  Tne  limitina  of 
be  a minor  chanae  to  the  lanquaqe.  Since  more  than  one  pointer 
may  be  bound  to  a sinole  'class'  variable  shared  data  structures 
can  be  achieved. 


It  is  clear  that  since  'class'  variables  are  dynamically  allocat- 
ed, recursive  data  structures  are  feasible.  However,  the  source 
documentation  does  not  specify  if  and  how  such  data  snace  is  de- 
allocated. Since  allocation  is  explicit  but  must  be  within  the 
bounds  of  the  pointer  scooe  it  would  aonear  that  references  could 
occur  orior  to  the  initial  allocation  unless  compiler  toooqraphi- 
cal  flow  analysis  is  included  or  run-time  checks  are  performed. 


Requ irement : El 


The  user  of  toe  lanquaoe  will  be  able  to  define  new  data  types 
and  operations  within  nroqrams. 


The  extensive  user  data  declaration  facilities  fully  satisfies 
the  "TINMAN"  reau i cement  for  definino  new  data  types. 


Operations  can  be  defined,  only  by  functions  or  procedures  which 
do  not  provide  a means  of  detinina  infix  operators.  The  require- 
ment to  define  new  infix  operators  would  aopear  to  be  in  conflict 
with  42  which  specifies  that  "new  infix  operator  precedence" 
shall  not  ne  definable.  If  new  infix  operators  are  to  be  defined, 
both  the  semantics  and  precedence  of  those  operators  would  re- 
quire definition  unless  tne-  definition  were  described  in  terms  of 
existinq  operators  in  which  case  the  precedence  is  implied. 


Requ  i r ement : if 2 


The  "use"  of  defined  types  will  be  ind i s t inou i shab le  from  built 
in  types. 


The  syntactical  structure  of  PASCAL  for  reference  to  any  identif- 
ier or  constant,  he  it  a built-in  or  user  defined  type  is  identi- 
cal thus  satisfyinq  this  requirement.  The  semantics  of  a state- 
ment referencino  data  types  is  a function  of  the  aeneral  class  of 
data  types  (e.q.,  scalars)  he  they  built-in  or  user  defined.  For 
example  a relational  test  of  scalar  identifiers  has  both  the  same 
syntax  and  semantics  if  tne  identifiers  represent  inteoers  or 
those  defined  by  enumeration. 


Requirement:  F.  1 


Each  oroqram  comoonent  will  he  defined  in  the  base  lannuaae,  in  a 
library,  or  in  the  proqram.  There  will  be  no  default  declara- 
tions. 


---Pa 


j 


The  base  lanauaae  provides  all  the  elementary  components  from 
which  more  complex  components  may  he  constructed.  The  construc- 
tions may  exist  in  tne  proqram,  or  it  tne  specific  implementation 
allows,  in  a library. 

In  qeneral,  there  are  no  default  declarations  within  the  lanquaoe 
with  the  exception  ot  the  constant  specific a tor,  const,  associat- 
ed with  formal  parameter  delcarations.  To  reouire  this  keyword 
would  be  a trivial  effort. 


Requirement:  F4 

The  user  will  be  able,  within  the  source  lanauaqe,  to  extend  ex- 
istina  operators  to  new  data  tynes. 


P 


The  operand  types  with  which  the  defined  set  of.  operators  can  be 
aoolied  is  specified  and  it  is  not  possible  to  extend  those 
operators  to  additional  variable  types.  However,  since  user  de- 
fined variable  types  fall  into  a qiven  set  of  qeneral  classes 
(scalars,  powersets,  etc.),  the  appropriate  existim  operators 
for  the  operands  qeneral  class  are  applicable. 


Requirement:  F5 


Type  definitions  tn  the  source  lanquaqe  will  permit  definition  of 
both  the  class  of  data  objects  comprisinq  the  tyre  and  set  of 
operations  applicable  to  the  class.  a defined  type  will  not  au- 
tomatically inherit  the  operations  of  the  data  with  which  it.  js 
represented. 


P 


User  defined  variable  tynes,  as  explained  in  FI,  fall  info  one  of 
several  c 1 ass i f icat i ons  . The  operations  pertinent  to  the  aeneral 
tyoe  are  inherited  and  cannot  oe  modified  by  the  user  oeclara- 
t ion. 


Requirement:  Fb 


r 


The  data  objects  comprising  a defined  type  will  be  definable  bv 
enumeration  of  their  literal  names,  as  cartesian  nrodncts  of  ex- 
isting tyDes  (i.e.,  as  array  and  record  classes),  bv  discriminat- 
ed union  (i.e.,  as  tne  union  of  disloint  tyoes)  and  as  the  Dower- 
set  of  an  enumeration  type.  These  definitions  will  be  processed 
entirely  at  comp i le-t Ime . 
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The  basic  definaole  data  tynes  are  the  scalar  tyres.  Their  de- 
finition indicates  an  ordered  set  of  values,  i.e.,  introduces  an 
identifier  as  a literal  constant  represent  inn  each  value  in  the 
enumerat ion  set . 


Structured  data  types  are  described  by  describino  the  types  of 
their  components  and  by  indicating  a structurinn  method.  both 
array  and  record  structure  are  construed  as  definitions  by  carte- 
sian products  since  they  provide  definitions  in  terms  of  other  in 
built  or  user  defined  tynes. 


Powerset  definition  is  exolicltlv  available  for  scalar  base 
tynes,  either  those  defined  by  enumeration  or  the  predefined 
tyoes  (inteaer,  etc.). 


. Definition  bv  union  of  disloint  sets  is  not  included  thouah  such 

sets  could,  of  course,  explicitly  be  defined  hv  enumeration  of 
all  of  tne  literal  elements  from  the  desired  disjoint  set.  filter- 
[v  natively  the  superset  could  bv  initially  defined  and  subsets  de- 

fined by  tne  subrange  types  feature.  With  either  approach,  it 
would  be  tne  users'  responsibility  to  ensure  that  the  subsets 
were  disloint. 

6 

**  To  add  a language  construct  to  provide  disjoint  union,  typing 

[ V,  would  be  considered  relatively  minor. 

M 

....................... 

a? 


Tyne  definitions  bv  free  union  (i.e., 
and  subsetting  are  not  desired. 


union  of  nondisjolnt  tyres) 


Type  definitions  by  free-union  are  not  available  in  PASCAL, 
Subranqinq  of  scalar  types  is  permitted  and  such  subranges,  con- 
trary to  the  "TIi'.vA'V  requirement,  are  construes  as  pea  data 
types.  To  alter  these  semantics  to  satisfy  the  requirement  would 
be  considered  a moderate  to  m.  a 1 o r task. 


Requirements  PR 


\ 


When  defininq  a type,  the  user  will  be  able  to  specify  the  ini- 
tialization and  finalization  procedures  for  tne  tvne  and  the  ac- 
tions to  oe  taken  at  time  of  allocation  and  deallocation  of  vari- 
able of  the  type. 


n.  The  source  documentation  used  for  this  report  did  not  specify 
if  and  how  allocated  data  is  deallocated.  However,  it  is  ap- 
parently not  explicit  and  thus  finalizatin  actions  cannot.  be 
specified. 


p 


Requirement:  FI 


The  lanquaae  will  allow  the  user  to  distinguish  between  scone  of 
allocation  and  scope  of  access. 


V 


The  PASCAL  block  structure  dictates  that  the  access  am  alloca- 
tion scopes  are  identical  with  the  exception  of  the  class  tyne 
variables.  Since  the  allocation  of  class  variables  is  dynamic 
and  explicit,  unless  a aiven  compiler  implementation  includes  to- 
pographical flow  analysis,  it  would  ne  possible  for  a user  to  at- 
tempt to  access  a class  variable,  via  a pointer,  outside  of  the 
allocation  scooe  of  that  variable. 


If' 


t: 


Requirement:  F2 


The  ability  to  limit  the  access  to  separately  defined  structures 
will  ne  available  ooth  where  tne  structure  is  defirei  eno  where 
it  is  used.  It  will  oe  possible  to  associate  new  local  names 
with  seDaratelv  defined  oroara""  components. 


The  reiuirement  is  partially  met,  as  oescriped  in  f.  j above. 


Requirement:  Fd 


The  scooe  of  identifiers  will  ne  wholly  determined  at  comnile> 
time. 


All  identifiers  must  oe  defined.  Access  to  an  identifier  is 
guaranteed  within  the  scooe  of  declaration.  Identifiers  may  be 
redefined  either  within  imoedded  scopes,  in  which  case  references 
apply  to  the  most  deeply  JmbeddPd  declaration  scope  surrounojno 
the  reference  or  within  disloint  scores.  Tnese  rules  ensure  that 
the  score  of  all  Identifiers  is  a function  of  the  nr oo ram's  stat- 
ic structure  and  are,  thus,  det erm i nah  l e at  compile-time. 


Reguirement:  F4 


A variety  of  aopiication  oriented  data  and  operations  will  be 
available  in  lioraries  and  easily  accessible  in  the  lanquaoe. 

p 


The  PASCAL  lanquaoe  does  not  provide  the  mechanise  for  includira 
co^ot  le-t  ime  library  files  in  which  application  oriented  data 
structures  could  be  ietined.  It  is  anticioated  that  for  any 
qiven  imolementation,  data  declaraton  tiles  could  ne  readily 
merged  either  by  an  extension  to  the  lanauaoe  or  a Dreorocessor. 


The  following  operations  are,  however,  assumed  to  he  predeclared 
in  every  implementation  of  PASCAL: 

out  (t)  Kile  oositionina  procedures. 

aet  C f ) 

reset  ( f ) 

alloc  (p)  Allocate  an  additional  component  to  a 

class  variable. 

pack  (a,  i,  z)  Pack  a character  array  into  an  alfa 

variable. 

unoack  (z,  a,  i)  Unoack  an  alfa  variable  into  a character 

array. 


set  is  x 


succ  Cx)  Scalar  functlor  for  finding  the  succes- 

sor value  of  x from  its  set. 

pred  (x)  Scalar  function  for  finding  the  prede- 

cessor value  of  x from  its  set. 


Further  the  language  specifies  that  any  implementation  mav 
feature  additional  oredeclared  functions  or  procedures. 


Requirement : F5 


Program  components  defined  within  the  current  program  and  not  in 
the  base  language  will  oe  maintained  in  compile-time  libraries. 
The  libraries  will  be  capable  of  holding  anything  definable  in 
the  language  and  will  not.  exclude  routines  whose  bodies  are  writ- 
ten in  other  source  languages. 


The  PASCAL  language  definition  does  not  address  the  concept  of 
externally  defined  modules  in  anv  form,  since  such  features  have 
t rad i t ional ly  been  considered  functions  of  the  compiler  environ- 
ment and  are  frequently  implementation  dependent.  However,  it  is 
believed  that  such  an  extension  could  readily  bp  appended  to  the 
PASCAL  language  for  a moderate  effort. 


Requirement:  F6 


Libraries  and  comoools  will  be  indistinguishable.  They  will  be 
caDable  of  holding  anything  definable  in  the  language  and  it  will 
be  possible  to  associate  them  with  any  level  of  programming  ac- 
tivity from  systems  throuah  projects  to  individual  programs. 
There  will  be  many  specialized  compools  or  libraries  any  user 
specified  subset  of  which  is  immediately  accessible  from  a given 
program. 


F 


The  language  definition,  as  with  Requirement  FS,  does  not  address 
compiler  and  run-time  environments  nor  any  references  to  items 
external  to  the  current  orogram.  in  the  practical  situation,  of 
course,  it  is  desirable  to  provide  the  facility  to  include  items 
defined  within  compools  and  to  explicitly  reference  library 
items.  To  ensure  the  integrity  of  tvpe  checking  would  require, 
at  least  for  library  references,  the  maintaining  of  compile-time 
data  in  addition  to  the  object  code. 


The  source  language  will  contain  standard  machine  independent  in- 
terfaces to  machine  dependent  capab i 1 i t i es  , includtno  re riPheral 
equipment  and  special  hardware. 


In  addition  to  the  soecitied  standard  1/U  procedures  for  access* 
ina  files,  the  1 anguage  definition  provides  for  an  extended  set 
of  standard  procedures.  This  feature  could  oe  readilv  utilized 
the  capabilities  for  this  requirement.  However,  it  would  be 
desirable  to  include,  as  part  of  the  lanauaae  definition,  the 
identifiers  and  protocol  of  those  procedures  to  ensure  that  stan- 
dardization could  be  achieved.  The  effort  to  do  this  cannot,  of 


course,  oe  estimated  until  the  specific  functions  required  are 


Requirement:  Cl 


The  1 anquaqe  will  provide  structured  control  mechanisms  for 
sequential,  conditional,  iterative,  and  recursive  control.  It 
will  also  provide  contro’  structure  for  (pseudo)  parallel  pro- 
cessinq,  exception  handlifq,  and  asynchronous  interrupt  handlim. 


] 


Sequential  control  . . 
Conditional  control 
Iterative  control  . . 
Recursive  controL  . . 
Parallel  processi*q 
Exception  handlinq  . . 
Asynchronous  interrupt 


T 
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The  languaqe  elements  which  provide  the  aoove  requirements  are 
ident i f led  below: 


IF:  The  / F statement  specifies  that  a statement  be  exe- 

cuted of ly  if  thf  specified  boolean  expression  is 
true.  If  it  is  false,  no  statement  is  to  be  executed 
or  the  alternate  statement  followino  the  connective 
ELSE  is  t.»  be  executed. 


CASE:  The  CASE  ftatement  consists  of  an  expression  (the 

selector)  and  a list  ot  statements,  each  labeled  by  a 
constant  »'  the  tyoe  of  the  selector.  It  specifies 
that  one  statement  be  executed  whose  label  is  eoual 
to  tne  current  value  of  the  selector. 


WHILE:  The  WHILE  statement  specifies  that  a statement  be  re- 

peatedly ettcuted  while  the  value  of  a boolean  ex- 
pression is  true.  It  its  value  is  false  at  the  be- 
qinninq,  the  statement  is  not  executed  at  all. 

REPEAT:  The  REPEAT  statement  specifies  that  the  sequence  of 

statements  between  the  symbols  REPEAT  and  UNTIL  are 
repeatedly  (and  at  least  once)  executed  until  the 
value  of  a boolean  expression  becomes  true. 

FOR:  The  FOR  statement  indicates  that  a statement  is  to  be 

repeatedly  exefited  while  a prooression  of  values  is 
assigned  to  a variable  which  Is  called  the  control 
variable  tor  tha;  statement.  Expressions  are  inclun- 
ed  to  specify  th  i initial  and  final  values  tor  the 
control  variable.  At  each  iteration,  the  value  of 
the  control  variable  is  replaced  by  either  the  suc- 
cessor or  oredeceisor  of  the  current  control  variable 


value.  The  cnoice  is  determined  py  use  of  the  alter- 
nate symbols  TO  o;  down  10  wnich  separates  the  ini- 
tial and  final  value  expressions. 

00  TO:  The  GO  TO  statement  »erves  to  indicate  that  further 

processing  should  continue  at  another  part’  of  the 
program  text,  namely  at  the  place  of  the  label.  The 
transfer  of  control' is  uncondi t ional . 


The  scoDe  of  access  of  a label  is  *imited  to  the  structure  in 
which  It  is  defined,  and  all  structures  defined  within  it,  with 
the  exception  of  procedure  and  tunrtion  defintions.  In  those  in- 
stances, it  is  invalid  to  branch  o if  of  or  into. 


Recursive  structures  are  available  in  the  form  of  procedure  de- 
clarations where  only  direct  recursion  is  valid.  This  property 
is  implied  by  a reference  to  a procedure  identifier  within  the 
executable  test  of  tne  same  procedure. 


Parallel  Drocessinq  is  not  explicitly  available  as  a structure  of 
PASCAL,.  If  it  were  to  be  included  01  a limited  basis  by  the  in- 
troduction of  definable  tastes,  in  a fishion  syntact  ica  1 ly  similar 
to  procedures  and  it  identifier  refer  i^ces  were  limited  to  local 
declarations  and  formal  parameters,  the  effort  would  be  moderate. 
If  capabilities  beyond  this  were  required,  extensive  considera- 
tion of  the  protocol  of  data  handlina  woild  need  to  be  defined. 


Similarly,  interrunt  handlina  is  not  explicitly  defined  thouqh 
they  could  no  processed  oy  the  inclusion  >f  further  standard  pro- 
cedures, and  suen  a metnod  may  prove  satif factory  if  anreement 
concernina  the  semantics  of  such  nroceaurev  could  be  reached. 


Requirement:  G2 


The  source  lanquaae  will  provide  a "GO  TO" 
within  its  most  local  scooe  of  definition. 


'deration  applicable 
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The  PASCAl,  GO  TO  statement  does  nqt  limit  the  referenced  label  to 
the  most  local  scooe.  The  labels  obey  the  ruies  of  all  identif- 
iers, in  that  the  scooe  of  access  includes  the  '-tructure  in  which 
it  is  defined  and  all  structures  d iclared  withi > the  structure  of 
def  inlt ion. 


Requirement:  G 1 
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The  conditional  control  structures  *1.’ 1 be  fully  partitioned  and 
will  permit  selection  among  alternative  computations  based  on  the 
value  of  a Boolean  expression,  on  the  subtype  of  a value  fro*  a 
discriminated  union,  or  on  a computed  choice  amono  labeled  alter- 
nat  i ves  . 


Based  on  Boolean  expression  T 

Based  on  subtype  from  discriminated  union  ....  T/U 
Based  on  computed  choice  ,....T 


The  IF  statement  provides  the  primary  control  structure  and  dic- 
tates that  the  condition  be  a Boolean  expression  as  required  by 
the  "TINMAN"*  Data  types  defined  ov  enumerator,  and  as  powersets 
thereof  may  utilize  the  IN  operator  which  may  be  construed  as  a 
di scr  iminat eo  union  but  returns  a Boolean  value.  The  CASE  state- 
ment provides  conditional  statement  execution  based  on  the  value 
of  a variable  of  any  type.  do  explicit  action  is  defined  for  a 
CASE  statement  should  the  value  of  the  expression  be  out  of  the 
bounds  specified  py  the  CASE  statement. 

The  IF  statement  is  not  fully  partitioned,  in  that  the  ELSE  sub- 
structure is  optional.  However,  the  semantics  of  the  folio wind 
statement  are  unambiguously  defined: 

IF  <exoress ion-1 > THEN  IF  <exrr e s s i on-2>  THEN  <statement-l > 

ELSE  <statement-2> 

by  interpreting  tne  construct  as  equivalent  to: 

IE  <express i on- 1 > THEN 

BEGIN  IF  <expression-2>  THEN  <statement-l> 
ELSE  <statement-2> 

END 

It  would  appear  that  the  intent  of  the  "TINMAN"  reauiremert  is 
net  though  it  requires  a semantic  definition  to  quality  the  ampi- 
quous  syntax. 


Require  rent:  G4 


The  iterative  control  structure  will  permit  the  ter»ination  con- 
dition anywhere  in  the  loon,  require  control  variables  to  pe  lo- 
cal to  the  iterative  Control,  allow  entry  onlv  at  th»  head  of  the 
looo,  and  not  impose  excessive  overhead  in  clarit/  or  run-time 
execution  costs  tor  common  special  case  termination  conditions 
(e.g.,  fixed  number  of  iterations  or  elements  of  /n  array  ex- 
hausted I . 
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Termination  anywhere  within  loon  P 

Local  control  variables F 

Fntry  at  Iood  head  only T 

Efficient  and  clear  simple  cases  T 


Control  value  availanle  at  termination  U 


The  iterative  structures  while,  HE PEAT,  and  FOR  »re  fully 
described  in  Gt  and  satisfy  the  aeneral  intent  of  thj  "TINMAN" 
requirement.  The  while  statement  provides  terminatioi  at  the 
head  of  a loon  while  the  HEPEAT  statement  provides  termination  at 
the  end  of  the  loon.  In  addition,  exit  may  be  achieved  from  any 
point  within  t ne  loor  by  comoinino  an  IF  statement  with  the  un- 
conditional GO  TO.  However,  use  of  such  a technique  does  not 
limit  oroaram  execution  to  the  statement  foilowino  the  iterative 
structure  as  is,  pernacs,  intended  by  this  requirement. 


The  control  variable  of  a FOR  statement,  wnich  nrovide/  for  a 
oredeter mined  number  of  iterations,  is  not  local  to  .terative 
structure  and  its  value  at  termination  is  undefined,  unless  ter- 
mination is  a result  of  a oranch  (GO  TO)  out  of  the  structure. 
The  only  restriction  concerning  the  control  varianle  is  that  it 
may  not  be  assioned  a value  within  the  structure. 


The  impact  of  fully  satisfyinq  this  requirement  would  require 
careful  consideration  of  the  total  lanauaqe,  since  it  may  violate 
the  general  rules  concernina  identifier  scope.  As  a result,  the 
anticipated  effort  involved  was  not  predicted. 


Requ  i rement : Gb 


Hecursive  as  well  as  nonrecursive  routines  will  oe  available  in 
the  source  languane.  It  will  not  be  possible  to  define  pro- 
cedures within  the  ooiy  of  a recursive  procedure. 


Recursive  and  nonrecursive  routines  T 

Explicit  specification  of  recursive  routines  . . . F 
No  procedure  definitions  within  recursive  routines  f 


PASCAI.  procedures  may  he  recursive,  but  apparently  only  direct 


recursion  Is  valid,  since  that  Property  is  implied  only  be  refer- 
ence to  a procedure  identifier  within  the  same  procedure  declara- 
tion. Recursive  procedures  are  rot  explicitly  declared.  In  ad- 
dition, all  identifiers  must  be  declared  prior  to  reference, 
thus,  orecludina  indirect  recursion  at  any  level.  A further  vio- 
lation of  the  "TINMAN"  requirement  is  that  procedure  declarations 
are  valid  witnin  more  qlooal  Procedure  declarations  be  they  re- 
cursive or  otherwise. 


As  a result  of  the  somewhat  unclear  lanauage  definition  concern- 
in’: indirect  recursion  and  the  uncertainty  of  the  "TINMAN"  on 
this  matter,  it  is  difficult  to  make  an  assessment  on  overall  im- 
pact. However,  it  is  safe  to  assume  that  at  best  it.  would  be 
moderate . 


Requirement:  G6 


The  source  lanquaqe  will  provide  a parallel  orocessina  capabili- 
ty. This  capability  should  include  the  ability  to  create  and 
terminate  (possible  oseudol  parallel  processes  and  tor  these 
processes  to  qain  exclusive  use  of  resources  durinq  specified 
portions  of  their  execution. 


The  lanquaqe  does  not  explicitly  provide  tor  parallel  orocessina, 
oseudo  or  otherwise.  This  item  was  discusseo  in  Section  Gl  of 
this  report  and,  although  any  extension  of  the  lanauaoe  to  satis- 
fy this  requirement  would  be  a maior  impact,  it  could  be  minim- 
ized if  constraints  described  in  Gl  were  provided.  The  net 
result  of  such  an  extension  would  onlv  partially  satisfy  this  re- 
quirement . 


Requirement:  G7 


The  exception  handlina  control  structure  will  permit  the  user  to 
cause  transfer  and  control  of  data  for  any  error  or  exception  si- 
tuation which  may  occur  in  a oroqram. 
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PASCAL  does  not  specifically  address  exception  handlino  as  there 
are  no  control  constructs  dedicated  to  that  function.  However, 
extensions  to  the  nebulous  'standard*  procedures  and  the  ability 
to  pass  procedure  identifiers  as  actual  parameters  to  procedure 
invocations  provides  an  exception  handlino  capability.  The  pro- 
tocol of  this  reoui rement  is,  thus,  not  dictated  oy  the  lanquaqe 


• wmm  1 1 mm  Mg  m i . m 


»rr 


and  wo'uld  require  rigorous  detinition  for  a aiven  system 


Addition  of  formally  defined  exception  handling  constructs  would 
oe  an  extensive  effort. 


Requirement:  G8 


There  will  be  source  lanouaqe  features  permit  delay  on  any  con- 
trol oath  until  some  specified  time  or  situation  has  occurred, 
which  permit  specification  of  the  relative  priorities  among 
parallel  control  paths,  oive  access  to  real  time  clocks,  permit 
asynchronous  hardware  interrupts  to  be  treated  as  any  other  ex- 
ception situation. 


This  requirement  appears  to  be  a consolidation  of  G 1 , GO,  and  G7 
addressing  interrupt  handling,  parallel  processing,  exception 
handling,  etc.  As  Previously  descrioed  within  those  sections,  it 
is  feasible  that  they  could  be  partially  satisfied  by  extensions 
of  existing  capabilities.  However,  since  PASCAL  does  not  specif- 
ically address  real  time  processing  it  is  probable  that  the  ex- 
tensions to  satisfy  tnese  requirements  should  take  the  form  of 
new  constructs  to  tne  language.  It  would  be  necessary  to  unoer- 
take  a detailed  analysis  of  tne  language  to  ensure  that  the 
around  rules  of  tne  current  language  are  not  violated  nor  are 
seriously  overlapping  functions  created.  These  criteria  may  seem 
obvious  but  an  examinatton  of  other  lanauages  reveals  that  incon- 
sistencies, incomplete  definitions,  and  functional  overlap  are 
all  too  often  encountered.  The  impact  on  the  language  to  satisfy 
this  requirement  would,  no  doubt,  be  major  but  without  a detailed 
analysis,  which  is  considered  beyond  the  scope  of  this  report,  an 
accurate  estimate  cannot  be  made. 


i 


Regu i r'ement : Ml 


Tne  source  language  will  be  tree  format  with  an  explicit  state- 
ment separator,  allow  tne  use  of  mnemonically  significant  iden- 
tifiers, be  based  on  conventional  forms,  nave  a simple  uniform' 
and  easily  parse!  grammar,  not  provide  unigue  notations  tor  spe- 
cial cases,  not  permit  abbreviation  of  identifiers  or  keywords, 
and  be  syntactically  unambiguous. 


- - - - p*  ---> 


Free  format  with  statement  separator  P+ 

Mnemonically  significant  identifiers  1 

Conventional  forms  T 

Mo  special  case  notations  1 

No  abnre viat ions  of  Keywords  or  identifiers  . . . T 
Unambiguous  grammar  P+ 


This  requirement  is  almost  entirely  satisfied.  The  discrepancies 
appear  below: 


The  source  language  is  totally  free  format  and  does  not  require  a 
statement  seoarator.  This  feature  is  achieved  by  the  simplicity 
of  the  syntax. 


There  aooears  to  be  only  a single  syntactical  ampjquity,  to  this 
evaluator,  concerning  the  ootional  ELSE  clause  of  an  IF  statement 
as  described  in  Section  G3  of  this  report.  The  ambiguity  is 
resolved  ov  a precise  semantic  definition.  Alternatively  the  de- 
ficiency could  be  solved  oy  defining  the  ELSE  clause  as  mandatory 
and  introducing  a null  statement  into  the  lanquaae.  This  latter 
feature  would  be  required  as  a result  of  lack  of  statement 
separator . 


Requirement:  H? 


The  user  will  not  oe  able  to  modify  the  source  lanauaqe  syntax. 
Specifically,  he  will  not  be  able  to  modify  operator  hierachies, 
introduce  new  precedence  rules,  define  new  keyword  forms,  or  de- 
fine new  operator  precedence. 


The  syntax  and  semantics  of  PASCAI  are  completely  defined  and  can 


neither  be  altered  nor  extended. 


He  -j  u i recent : Hi 


The  syntax  of  source  language  programs  will  be  composable  from  a 
character  set  suitanle  for  ounlication  ourooses,  nut  no  feature 
of  the  language  will  ne  inaccessible  using  the  b4  ASCII  character 
subset . 


Although  the  required  character  set  is  considered  suitable  for 
publication,  the  R?  unique  characters  preclude  the  use  of  an 
ASCII  subset.  Reduction  of  the  character  set  could  be  reduced  to 
conform  to  that  requirement  by  restricting  alphabetic  characters 
to  a single  case. 


Requirement:  H4 


The  language  definition  will  orovide  the  formation  rules  tor 
identifiers  and  literals.  These  will  include  literals  for 

numbers  and  character  strings  and  a break  character  for  use 


internal  to  identifiers  and  literals. 

Numeric  literals  T 

Character  string  literals  T 

Break  character F 


A break  character  is  not  included  within  the  valid  character  set 
out  could  readily  oe  added,  however,  since  the  language  is  total- 
ly free  form  it  does  not  appear  to  he  necessary. 


Requirement:  Hb 


Thpre  will  be  no  continuation  of  lexical  units  across  lines,  but 
there  will  be  a way  to  include  object  characters  such  as  end-of- 
line  in  literal  strings. 


1 


h 
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The  free  format  of  PASCAL  precludes  the  recognition  of  lines 
within  the  source  incut.  To  include  ooiect  characters  in  charac- 
ter strings  is  feasible  and  would  be  a trivial  chanae. 


Requirement:  Hn 


Key  words  will  be  reserved,  be  very  few  in  number,  be  informa- 
tive, and  not  be  usable  in  contexts  where  an  identifier  can  be 
used. 


PASCAL,  contains  only  30  reserved  keywords  which  is  consioered 
very  few  for  a language  of  this  nower.  The  predefined  procedure 
identifiers  are  not  included  in  this  count. 


Reouirement:  H 7 


The  source  language  will  have  a single  uniform  comment  conven- 
tion. Comments  will  be  easily  distinguishable  from  code,  be  in- 
troduced oy  a single  (or  possibly  two)  language  defined  charac- 
ters, nermit  any  comninatton  of  characters  to  appear,  be  able  to 
aooear  anywhere  reasonable  in  programs,  automatically  terminate 
at  end  of  line  if  not  otherwise  terminated,  and  not  prohibit  au- 
tomatic reformatting  of  programs. 


Single  comment  convention  T 


i 


Distinguishable  from  code 


P 


Introduced  by  one  or  two  characters 


Contain  any  character 


Appear  anywhere  reasonable 


Terminate  of  end-of-line 


dot  r>ronioit  reformatting 


Comments  in  the  pascal  language  may  appear  any  two  lexical  units 
( i ,e . , identifiers,  numbers,  operators,  etc.),  are  introduced  and 
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terminated  py  unique  symbols,  land!  respectively,  thus  nrecludina 
t ne  use  of  the  ter minat inn  symbol,  1,  as  a comment  character.  As 
a result,  it  is  oronaole  that  to  a human  reader  comments  are  not 
"easily  di st inquishaole  from  code".  Inis  subr eou i r ement  appears 
to  conflict  witn  that  requirinq  "an  combination  of  characters  to 
appear".  However  compilers,  obviously,  would  have  no  problem  in 
distinquishinq  comments  from  source  code. 

Comments  are  not  terminated  ny  an  end-of-line  since  the  free  for- 
mat nature  of  the  lanquaoe  does  not  recoqnize  the  end-of-line  en- 
tity. 


Requirement:  H9 


The  lancr.iaae  will  not  permit  unmatched  parenthesis  of  any  Kind, 


Requirement:  HO 


There  will  be  a uniform  referent  notation. 


Entire  variables  are  referenced  by  the  variable  identifier  name. 
A component  of  a variable  is  referenced  by  the  denotation  of  the 
variable  identifier  followed  by  a selector  snecifvina  the  com- 
ponent. The  form  of  tne  selector  depends  on  the  structurino  type 
of  the  variable.  However,  for  each  structurino  tyre  references 
are  consistent  and  this  evaluator  assumes  that  this  is  the  intent 
of  this  requirement.. 


Requirement:  H10 


Mo  lanquaqe  defined  symbols  aopearim  in  the  same  context  will 
have  essentially  different  meaninas. 


The  qrammar  of  PASCAL  is  truly  context  free. 


* Requirement:  II 


There  will  t>e  no  let  -suits  in  programs  wnich  at  feet  the  program 
logic.  That  is,  decisions  which  affect  program  loaic  will  dp 
marie  irrevocable  when  the  language  is  riefineo  or  explicitly  in 
each  program. 


The  structure  of  PASCAL  requires  all  identifiers  to  be  oetineri 
prior  to  reference  aori  each  executable  statement  is  entirely  ex- 
plicit thus  eliminating  all  of  the  traditional  defaults.  Hov.ev- 
er.  the  collating  sequence  of  the  alfa  character  set  is  not  a 
function  of  the  language  and  will  differ  from  one  implementation 
to  the  other.  This  characteristic  could  be  consideren  an 
unalterable  default  though  it  is  unllkelv  to  nave  anymore  than  a 
minor  impact  if  the  programming  authorities  are  aware  of  the  col- 
lating sequence  for  a specific  implementation. 


Requirement:  I? 


Default  capabilities  will  bp  provided  for  special  capabilities 
affecting  only  object  representation  on  other  properties  which 
the  programmer  does  not  Know  or  care  about.  Such  defaults  will 
always  mean  that  the  programmer  does  not  care  which  choice  is 
marie.  The  programmer  will  be  aoie  to  override  these  defaults 
when  necessary. 


This  requirement  aooears  to  be  Primarily  addressing  the  internal 
algorithms  of  a comoiler  wnich  affpct  the  oblect.  representation 
of  data  and  object  code  generated  but  do  not  affect  the  function- 
al logic.  The  PASCAL  language  definition  does  not  address  this 
sup lect . 


Requirement:  13 


The  user  will  be  able  to  associate  compi  le-t ime  variables  with 
programs.  These  will  include  variables  wnich  sneclfy  the  oblect 
computer  model  and  otner  aspects  of  tne  oblect  machine  configura- 
tion. 


Although  the  language  includes  the  feature  of  association  data 


constants  with  compile-time  identifiers,  as  defined  in  section  D1 
of  this  report,  however,  those  identifiers  may  only  he  used  lo- 
cally and  do  not  address  the  oblect  machine  environment.  The  re- 
quired features  could  he  addea  to  the  lanouaqe  at  modest  cost, 
however,  the  cost  of  a given  system  would  he  closely  related  to 
the  characteristics  of  that  system. 


Requirement:  14 


The  source  lanouaqe  will  Permit  the  use  of  conditional  statements 
(e.q.,  case  statements)  dependent  on  the  object  environment  and 
other  compiler  time  variables.  In  such  cases,  the  conditional 
will  be  evaluated  at  comoile-time  and  only  the  selected  Dath  will 
be  comp i led. 


The  R ft  SC  A Li  lanouaqe  contains  the  necessary  features  to  satisfy 
this  requirement  (i.e.,  compile-tiTe  identifiers  and  case  state- 
ments), however,  it  is  not  defined  if  compile-time  evaluation  of 
"constant"  expressions  and  conditional  compilation  is  a lanauaoe 
feature.  In  qeneral,  tnis  decision  would  oe  left  to  the  compiler 
designer.  It.  would,  of  course,  he  trivial  to  necessitate  such 
features  by  including  them  in  tne  language  definition. 


Requirement:  15 


The  source  lanauaqe  will  contain  a simple  clearly  identifiable 
base  or  Kernel  which  houses  ail  the  power  of  the  language.  To 
the  extent  nossiole,  the  rase  will  be  minimal  with  each  feature 
providing  a single  unique  capability  not  otherwise  duplicated  in 
the  oase.  The  cnoice  of  the  case  will  not  detract  from  tne  effi- 
ciency, safety,  or  un  ler st andabi 1 i ty  of  the  language. 


This  language,  like  its  oredecessor  ALGO-bh  contains  a minimum 
base  language  from  which  more  complex  cpmponents  m^y  be  con- 
structed. Declarative  statements  are  of  two  (21  basic  tyres: 
data  declarations  and  or ocedure/f unct ion  declarations.  Kxrcut- 
able  statements  are  of  eight  (rt)  basic  tvoes;  assignment,  pro- 
cedure invocation,  if,  case,  while,  repeat,  for,  and  go  to 
resulting  in  a total  of  ten  ( 1 o ) basic  statements.  Though  not  a 
theoretical  minimum,  tne  Dower  realized  by  tnis  choice  of  state- 
ments would  appear  to  be  close  to  optimum. 


The  design  objectives  of  PASCAL  included;  systematic  structure, 
flexibility  of  program  and  latat  structuring,  and  efficient  irr- 
Dlementapility.  This  reviewer  feels  that,  those  goals  have  been 
•net  . 


Requirement:  16 


Language  restrictions  which  are  dependent  only  on  the  translator 
and  not  on  the  oolect  machine  will  be  specified  explicitly  in  the 
language . 


Information  pertaining  to  translator  dependent  limits  are  not  de- 
finaole  within  tne  language.  The  effort  to  include  a translator 
environment  definition  would,  in  most  instances,  he  major. 


Requirement:  17 


Language  restriction  which  are  inherently  dependent  only  on  the 
object  environment  will  not  be  built  into  the  lanouaoe  definition 
or  any  translator. 


As  with  other  requirements  concerning  translator  and  object,  en- 
vironments, information  was  not  available  from  the  language  de- 
finitions. The  language  itself  does  not  contain  any  restrictions 
which  are  dependent  upon  the  object  environment,  however,  it  is 
not  unreasonable  to  assume  that  translators  exist  with  such  res- 
trictions. 


Requirement:  J1 


Tne  lanauaqe  and  its  translators  *111  not  impose  run-tine  costs 
for  unneecled  or  unused  generality.  They  *111  ne  capable  of  pro- 
ducing efficient  code  tor  all  programs. 


The  source  material  used  tor  this  evaluation  was  limited  to  a 
language  definition  and  did  not  address  virtual  or  real  transla- 
tors. It  is  this  reviewers  on  inion  that  the  efficiency  of  the 
object  reoresentation  is*  to  no  small  extent,  a function  of  the 
inaenuity  of  the  translator  desianer  and  the  environment  in  which 
tne  oolect  code  will  be  invoiced.  However,  tne  hidhlv  structured 
nature  and  syntactic  consistency  of  the  language  will  provide  a 
hosnitaole  environment  for  implementind  efficient  and  reliable 
translators  on  presently  available  computers. 


Requirement:  d2 


Any  optimizations  performed  by  a translator  will  not  chanae  the 
effect  of  the  program. 


As  previously  explained,  Information  performing  to  specific 
translators  was  not  available  to  this  reviewer.  It  would,  howev- 
er, aoDear  to  be  mandatory  for  any  translator  optimization  that 
the  broqram  loqic  not  be  effected. 


Requirement:  Ji 


Tne  source  lanauaqe  will  orovide  encapsulated  access  to  machine 
dependent  hardware  facilities  including  machine  lanouaae  code 
insertions. 


p 


PASCAL  does  not  suDport  machine  lanquaqe  insertions,  however,  ex- 
tendin'! tne  standard  procedure  set.  would  provide  a mechanism  for 
referencing  encapsulated  machine  routines.  Such  routines  would 
require  a detailed  Knowledge  of  the  parameter  hanrilinq  protocal 
and  thus  would  he  a function  of  the  translator  imp  l e"-entat  i on  and 
the  run-time  executive  environment. 


Requirement:  J4 


It  will  oe  possible  within  the  source  lanquaqe  to  specify  the  ob- 
ject presentation  of  composite  data  structures.  These  descrip- 
tions (Kill  be  optional  and  encapsulated  and  will  distinct  form 
the  loaical  description.  The  user  will  be  able  to  specify  the 
time/space  trade-off  to  the  translator.  ff  not  specified,  the 
obiect  representation  will  be  optimal  as  determined  by  the  trans- 
lator . 


The  ohysical  description  of  the  object  representation  of  compo- 
site data  structures  cannot  be  specified  from  within  the  source 
of  PASCAL  orodrams.  It  is,  however,  feasiole  that  a translator 
could  include  optimization  cased  upon  the  loaical  description  and 
usaoe . 


The  anticipated  effort  of  includinq  explicit  physical  specifica- 
tions of  data  opjects  would  oe  major. 


Peou  i rement : .lb 


The  oroarammer  will  oe  aole  to  specify  whether  calls  on  a routine 
are  to  nave  an  ooen  or  closed  implementation.  An  open  and  closed 
routine  of  the  same  description  will  have  identical  semantics. 


f 


* 


* 


The  PASCAL  lamuaqe  definition  implies  that  all  oroceoure  defini- 
tions will  be  implemented  as  closed  suoroutines  thus  this  re- 
quirement is  not  met.  The  inclusion  of  an  ooen  routine  facility 
would  be  moderate  if  it  were  explicitly  defined  as  such.  Howev- 
er, it  the  translator  were  reouired  to  ontimallv  determine  an 
ooen  or  closed  implementation  the  impact  would  be  major. 


I 


^ * * PASCAL  EVALUATION  SUMMARY 

r 

This  section  provides  a too  level  summary  of  the  evaluation  of 
the  PASCAL  lanouaqe.  Those  functions  of  the  lanouaoe  which  qen- 
erally  satisfy  tne  H rj  fj  soec 1 f i cat i on  are  highlighted,  as  are  the 
deficiencies.  Deficiencies  are  furtner  classified  into  those 
which  would  require  ma  lor  and  those  which  would  reauire  minor 
modification  to  satisfy  the  HO L requirements. 


The  develoDment  of  PASCAL  was  based  on  two  principal  aims.  The 
first  was  to  make  available  a systematic,  disciplined  program mina 
lanouaoe  based  on  a minimum  number  of  fundamental  concepts  which 
were  clearly  ana  naturally  reflecteo  by  the  lanouaqe.  The  second 
was  to  develop  implementations  of  the  language  which  werf  both 
reliable  and  efficient  on  presently  availaole  computer/,  thus 
disoellino  the  commonly  accepted  notion  that  useful  lai ouaoes 
must  be  either  slow  to  compile  or  slow  to  execute,  and  the  oelief 
that  any  non-trivial  system  is  bound  to  contain  mistakes  forever. 
A further  airtr  was  to  provide  data  structures  and  functions  to 
make  it  possible  to  solve  both  commercial  and  scientific  ; r obiems 
to  help  erase  the  mystical  oelief  that  those  disciplines  must  be 
seqr eoated . 


PASCAL  includes  the  followino  character istics  which  satisfy  the 
requirements  of  the  HOL  specif ication : 


Concise,  well  defined  syntax  providina  maximum  structural 
flexibility  with  the  minimum  of  primitives  and  syntactic 
structures.  Few  keywords  are  required;  word  abbreviations 
are  not  permitted  and  lanouaqe  statements  are  free  format. 


Stromly  typed  identifiers,  including  pointer  tv*  es,  with 
well  defined  semantics  which  generally  or oh i h , t implicit 
data  type  conversions;  extensible  data  types  bv  e;  urrerat  i on , 
sub-ranoino  and  oowersets. 


M 


Structured  complex  composite  data  structures,  i.e.,  arrays 
of  records,  etc.,  providina  almost  unlimited  compositions  of 
the  primitive  data  types. 


Block  structured  environment  providina  clearly  discernible 
scooes  of  activity  and  limited  recursive  capabilities. 


Minimum  set  of  ore-defined  standard  functions  and  ; rocedures 
which  may  readily  be  extended  to  optimize  system  o/rtormance 
for  specific  purposes. 


Universal  usage  of  expressions,  of  appropriate  tv»e,  wnerev- 
er  a value  is  required. 
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Minimi zat ion  of  side  effects  bv  limiting 
ences  in  functions  to  local  identifiers 
sianments  to  formal  parameters. 


ident i f 1 er  ref er- 
and  disallowing  as- 


1 


With  only  one  exception,  defaults  are  not  permitted. 


Language  structure  is  sucn  that  efficient  imp  lementat.  ions 
should  oe  readily  obtained. 


Conversely,  PASCAL,  includes  the  following  character  if  t ics  which 
either  conflict  or  are  deficient. 


Absence  of  fixei-ooint  data  types. 


Absence  of  range  and  resolution  for  floatina  oolnt  data  ele- 
ments . 


Alternate  record  structures  are  selected  by  a finale  "taa" 
field  in  conflict  with  the  hhl  requirement  for  selection  by 
a general  Boolean  expression. 


Relaxation  of  tyoe  checking  for  assignments  wren  dependent 
varianle  is  real  and  expression  is  intea*  r or  jnt.eqer 
subrange  and  where  expression  is  subrange  of  dependent  vari- 
able type. 


Variable  number  of  arguments  to  procedures  i.  not  supported. 


Absence  of  explicit  control  structures  tor  oirallel  process- 
ing, exception  handling  and  asynchronous  interrupts. 


Language  does  not  address  real-time  control  functions,  i.e., 
control  oath  delay,  etc. 


Apparent  absence  of  conditional  cooilation  facilities  based 
upon  compile  time  variables  specifying  orlect:  computer  en- 
vironment . 


Physical  description  of  obiect.  data  representation  is  not 
supported. 


Open  subroutines  are  not  supported. 


Recursive  subroutines  are  not  explicitly  defined  but  are 
only  implied  by  loca  references. 


Modification  of  PASCAL  to  more  fully  support  tne  HOL  specifica- 
tion would  he  feasible.  As  detailed  in  tnis  report,  some  of  the 
modifications  would  be  minor,  while  others  would  he  relatively 
major  efforts,  and  costlv.  Those  in  the  former  aroup  include; 
fixed  point  data  tvoes,  ranae  and  resolution  specification,  com- 
pile or  load  time  evaluation  of  constant  exoressjons,  etc.  Those 
in  the  latter  orouo  include;  extension  of.  operators  to  new  data 
types,  seperaf.ion  of  allocation  ana  access  scopes,  parallel  nro- 
cessirn  and  selection  of  onen/closed  subroutines.  In  addition  to 
these  latter  items,  there  are  a number  of  requirements  which  are 
in  conflict  with  the  oasis  of  PASCAL  and  could  not  readilv  ne 
solved  without  chiniinq  tne  concent  of  tnaf  lanouaae.  The  most, 
significant  of  these  are  those  concerninq  the  treatino  of 
subrange  types  as  of  the  same  qeneral  type  as  tne  base  type  and 
the  concent  of  aeneric  procedures  where  the  formal  parameters  are 
not  fully  specified.  It  is  oelieved  by  this  reviewer  that  the 
intent  of  the  former  is  satisfied  by  relaxinq  type  checkinq 
between  base  and  subranne  tvpes.  Tne  latter  poses  more  of  a 
problem  since  it  is  difficult  to  envisaae  how  formal  parameter 
specifications  couli  be  made  optional  without  beino  inconsistent 
with  the  type  checxinq  convention  of  the  lanouaqe  and  in  tact, 
the  qeneral  HOL,  requirements  of  tvre  consistency. 


In  conclusion,  it  is  the  belief  of  this  reviewer  that  PASCAL  sa- 
tisfies most  of  the  salient  point  of  the  HOL  requirement.  with 
modifications  and  the  acceotance  of  meetinq  the  intent  of  some 
HOL  requirements  tnouqh  not  necessarily  explicitly  PASCAL  should 
encompass  the  total  HOL  requirements. 
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This  renort  presents  an  evaluation  ot  the  basic  CS-4 
language  with  the  requirements  listed  in  the  "Tinman". 
(DOD  requirements  for  high  order  computer  proaramning 
languages,  "Tinman"  - 1 March,  197b,  Section  IV)  For  pur- 
poses of  comparison  CS-4  is  considered  to  be  defined  hv: 

CS-4  Language  Reference  Manual  and  Operating  System 
Interface. 

Intermetrics, inc.  , Cambridge,  '"ass.  , October,  1975. 

There  are  79  language  requirements  listed  in  section  4 of 
the  "Tinman".  This  report  compares  basic  CS-4  with  each 
individual  requirement.  A summary  of  the  degree  to  which 
the  language  satisifies  each  requirement  is  presented. 

The  introductory  Paragraph  of  each  "Tinman"  requirement, 
is  included  as  the  leading  section  for  each  requirement 
evaluat i on . 

Symbols  Placed  beside  each  individual  requirement  indi- 
cate the  degree  to  which  the  language  meets  the  require- 
ment. The  symools  and  their  meaning  are  as  follow: 

T - Totally  meets  requirement 

P - Partially  meets  requirement 

F - Does  not  meet  requirement 

U - Unknown  from  available  documentation 

A summary  ot  the  evaluation  is  included  as  the  last  sec- 
tion of  this  report.  Merits  and  failures  of  the  language 
as  it  currently  is  defined  are  discussed.  Also  discussed 
are  the  potential  language  modifications  that  can  be  maoe 
to  support  DoO  "Tinman"  requirements. 

Note:  In  the  following  text  references  to  "CS-4"  always 
implv  basic  CS-4.  Any  references  to  full  CS-4  will  be  ex* 
olici t. 


* 


A.  DATA  AND  TYPES 


Requirement:  A1 

The  lanouaqe  will  be  typed.  The  tvpe  (or  mode)  of  all 
variables,  components  of  composite  data  structures,  ex- 
pressions, operations,  and  parameters  will  re  determin- 
able at  compile  time  and  unalterable  at  run  time.  The 
lanauaqe  will  require  that,  the  type  of  each  variable  and 
component  of  composite  data  structures  be  explicitly 
specified  in  the  source  nroqram. 


CS-4  totally  meets  this  requirement. 


Reoiii  rement : A? 

The  lanouaoe  will  provide  data  types  tor  inteqer,  real 
(floating  point.  and  fixen  point),  boolean  and  character 
and  will  provide  arrays  (i.e.,  composite  data  structures 
with  indexible  components  of  homooeneous  type)  and 
records  (i.e.,  composite  data  structures  with  labeled 
components  of  her eroueneous  type)  as  type  nenerators. 


Inteaer T 

fixed  point... F 

Floatinn  point. T 

Character  strim T 

Roo  lean T 

Arrays I 

Records T 


CS-4  does  not  provide  a seperate  fixed-point  mode.  The 
CS-4  mode  FRACTION  provides  tor  the  special  case  of  a 
floatinq  real  with  an  exponent  of  zero. 


Requirement:  A ) 

The  source  lanouaoe  will  require  qlohaJ  (to  a scope) 
specification  of  the  precision  for  tloatino  point  arith- 
metic and  will  permit  precision  specification  for  indivi- 
dual variables.  This  specification  will  be  interpreted  as 
the  maximum  precision  reouired  hy  the  nroqram  loqic  and 
the  minimum  precision  to  be  supported  by  the  oblect  code. 

CS-4  meets  this  requirement  totally  for  all  numeric  data 
modes  . 


Requirement : A4 


Rixed  point  numbers  will  be  treated  as  exact  quantities 
which  nave  a ranoe  an.1  a fractional  step  size  wnicn  are 
determined  by  the  user  at  compile  time.  Scale  factor 
manaqement  will  be  done  bv  the  compiler. 

CS-4  does  not  support  fixed  ooint  tyred  data. 


Requirement:  15 

Character  sets  will  be  treated  as  any  other  enumeration 
t yne . 

CS-4  provides  for  a sinqle  character  set  (revised  ASCII). 


Requirement:  Ah 

The  lanauaoe  will  require  user  specification  of  the 
number  of  dimensions,  the  rame  of  subscript  values  for 
each  dimension,  and  the  type  of  each  array  component, 
rne  number  of  dimensions,  the  tyne  and  the  lo»er  sub- 
scrint  bound  will  he  determinable  at  compile  time.  The 
upper  suoscript  bound  will  be  determinable  at  entry  to 
the  array  allocation  scone. 


Mumber  of  dimensions  fixed  at  compile  time T 

Tyne  fixed  at  compile  time T 

Lower  suoscriot  bound  fixed  at  compile  time....T 

Subscripts  from  continuous  rame T 

Subscripts  from  enumeration  type T 

Upper  suoscribt  bound  fixed  at  scooe  entry T 


CS-4  totally  meets  this  requirement. 


i 

Requirement:  A7 


The  lanauaqe  will  permit  records  to  have  alternative 
structures,  each  of  which  is  fixed  at  compile  time.  The 
name  and  type  of  each  record  component,  will  be  specified 


R.  OPERATIONS 


Requirement:  01 

Assinnment  and  refprence  operation  will  he  artom.at i ca  1 1 v 
defined  for  all  data  types  which  do  not  manaoe  their  data 
storaqe.  The  assignment  operation  will  permit  any  value 
of  a qiven  type  to  be  assigned  to  a variable,  array  or 
recoro  component  of  that  type  or  of  a union  type  contain- 
ina  that  type.  Reference  will  retrieve  the  last  assianed 
value. 

T 


Variable  declaration  for  all  data  types T 

Encapsulated  type  declaration T 

Array  or  record  declaration T 


CS-4  totally  meets  this  requirement. 


Requirement:  B2 

The  source  lanouaqe  will  have  a built-in  operation  which 
can  be  used  to  compare  any  two  data  oblects  (reoaroless 
of  type)  for  identity. 


CS-4  totally  meets  this  requirement. 


Requirement:  HI 

Relational  operations  will  be  automatically  defined  for 
numeric  data  and  all  types  defined  bv  enumeration. 


CS-4  totally  meets  this  reauirement. 


Requirement:  B4 

The  built-in  arithmetic  ooerations  will  include:  addi- 

tion, subtraction,  multiplication,  division  with  a real 
result),  exponentiation,  inteqer  division  (with  inteqer 
or  fixed  ooint  arouments  and  remainder),  and  negation. 

P 


Addition T 

Subtract  ion r 

Multiplication T 

Division  (with  real  result) T 

Neaat  ion  T 

Exponent  latl  on T 

Division  with  remainder F 


CS-4  provides  the  majority  of  the  arithmetic  operations 
specified  in  B4  with  the  followinq  execeptions: 

(a).  The  CS-4  operation  IDIV  provides  tor  inteqer 
division  of  the  various  numeric  types  with  no  capability 
for  access  of  remainder. 

(o)  Fixed  point  operations  are  not  supported  (see 
requirement  42). 


Requirement:  B5 

Arithmetic  and  assignment  operations  on  data  which  are 
within  the  ranqe  specifications  of  the  program  will  never 
truncate  the  most  sionificant  diqits  of  a numeric  quanti- 
ty. Truncation  and  roundinq  will  always  be  on  the  least 
sionificant  diqits  and  will  never  be  implicit  for  in- 
tegers and  fixeo  point,  numbers.  Implicit,  roundinq  beyond 
the  specified  precision  will  be  allowed  for  floatinq 
point  numbers. 


CS-4  totally  meets  this  requirement. 


Requirement:  Bh 

The  built-in  boolean  operators  will  include  "and",  "or", 
"not",  and  "nor".  The  operations  "and"  and  "or"  will  be 
evaluated  in  short  circuit  mode. 


Short  circuit  "and" T 

Short  circuit  "or" T 

Not T 

Nor T 


CS-4  totally  meets  this  requirement. 


Requirement:  H7 

The  source  language  will  permit  scalar  operations  and  as- 
signment on  conformable  arrays  and  will  permit  data 
transfers  between  records  or  arrays  of  identical  loaical 
structure . 

T 


Assignment  between  records  and  arrays T 

Scalar  ooerations  on  arrays T 


CS-4  totally  meets  this  requirement. 


°equirement:  HP 


There  will  be  no  implicit,  type  conversions  but  no  conver 


sion  operation  will  be  required  when  the  type  of  an  actu- 
al parameter  is  a constituent  of  a union  tvre  which  is 
the  formal  oarameter.  The  lamuaqe  will  DrovHe  explicit 
conversion  operations  amonq  inteoer,  fixed  point  and 
floatinq  point  data,  between  the  oolect  representation  of 
numbers  and  their  representations  as  characters,  and 
netween  fixed  ooint  scale  factors. 


Kxnlicit  conversions U 

No  implicit  conversions T 

Explicit  n e t w e e n scale  factors F 


Implicit  conversion  between  modes  in  CS-4  is  not  nremit- 
ted.  No  explicit  conversion  operations  are  defined  in  the 
available  documentation. 


Require  mi  ent:  B 9 

Fxolicit  conversion  operations  will  not  he  required 
between  numerical  ranqes.  There  will  be  a run  time  excep- 
tion condition  when  any  inteoer  or  fixed  point  value  is 
truncated. 

T 


CS-4  totally  meets  this  requirement. 


Requirement:  Bio 

The  base  lamuaae  will  provide  operations  allowina  pro- 
orams  to  interact  with  files,  channels  or  devices  includ- 
im  terminals.  These  operations  will  permit  serdino  and 
receivinq  both  data  and  control  information,  will  enable 
nroqrams  to  dynamically  assian  and  reassiqn  I/n  devices, 
will  provide  user  control  for  exception  conditions,  and 
will  not  oe  installation  dependent.. 

"The  CS-4  Gneratinq  Svst.em  Interface"  provides  extensive 
I/O  operations,  tnese  facilities  however  are  extensions 
of  the  basic  lamuaoe  definition  and  therefore  are  not 
included  in  tnis  evaluation.  No  1/n  operations  are  de- 
fined for  basic  CS-4. 


Requirement:  nil 

The  lanquaoe  will  provide  operations  on  data  types  de- 
fined as  power  sets  of  enumeration  tvpes  (see  f-n).  These 
operations  will  incluae  union,  intersection,  difference, 
complement,  and  an  element  predicate. 

CS-4  totally  meets  this  requirement. 
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C.  EXPRESSION S AN!)  PARAMETERS 


Requirement:  Cl 


Side  effects  which  are  dependent  on  the  evaluation  order 
amona  the  arguments  of  an  expression  will  be  evaluated 
let t-to-r iaht . 


CS-4  totally  meets  this  reauirement, 


Requirement;  C? 


Which  carts  of  an  expression  constitute  the  ooeranns  to 
each  oDeration  within  that  expression  should  be  obvious 
to  the  reader.  There  will  be  few  levels  of  operator 
hierarchy  and  they  will  be  widely  recoani/ed. 


Unambiguous  presentation T 

Few  precedence  levels T 

Peouire  explicit  parentheses F 

No  user  defined  levels T 


in- 


E'XDiicit  parentheses  are  not  reauired/in  expressions 
volvinq  operators  of  eaual  precedence. 

Full  CS-4  provides  facilities'  for  definin  new 
ore* , dos t - , and  infix  operators  and  attachinq  precedence 
to  their  evaluation.  Existino  operator  precedence  cannot 
be  redefined. 


Peaui rement : C3 


Expressions  of  a qiven  tyne  will  be  permitted  anywhere  in 
source  Droqrams  where  both  constants  and  references  to 


< 


variables  of  that  type  are  allowed 


CS-4  totally  mppts  this  requ  i r eirent . 


Requirement:  C4 

Constant  expressions  will  be  allowed  in  nroarams  anywhere 
constants  are  allowed,  a n q constant  expressions  will  be 
evaluated  before  run  tine. 

CS-4  totally  Tieets  this  requirement. 


Requirement:  CS 

There  will  ne  a consistent  set  of.  rules  applicable  to  all 
parameters,  whether  they  be  for  procedures,  for  types  for 
exception  nandlino,  for  parallel  processes,  tor  declara- 
tion, or  tor  built-in  operators.  There  will  be  no  spe- 
cial operations  (e.o.,  array  structurinq)  applicable  only 
to  parameters. 


Consistency  in  raram.eter  rules T 

Mo  special  parameter  operations T 


CS-4  totally  meets  this  requirement. 
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Requirement:  Cb 

Formal  and  actual  parameters  will  always  aqree  in  type. 

The  number  of  dimensions  for  array  parameters  will  tie 
determinant  at  compile  time.  The  size  ann  subscript 
ranoe  for  array  parameters  need  not  be  deter  it.  inable  at 
compile  time,  out  can  ne  rassed  as  part  of  the  parameter. 


Dimensions  determined  at  compile  time T 

Size  and  subscripts  can  be  passed T 

Tyoe  aareement  tor  actual  and  formal  parameters T 


CS-4  tp tally  meets  this  requirement. 


Requirement:  C7 


There  will  be  four  classes  of  formal  parameters.  For 
data  there  will  be  those  which  act  as  constants 
reoresenfino  the  actual  parameter  value  at  time  of  call, 
and  those  which  rename  the  actual  parameter  which  must  he 
a variable.  In  addition,  there  will  be  a formal  Parame- 
ter class  tor  soecityino  the  control  action  when  excep- 
tion conditions  occur  and  a class  for  procedure  parame- 
ter s . 
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Parameter  constants T 

Parameter  variables T 

Exception  conditions F 

Procedure  parameters  . . T 


CS-4  does  not  provide  a formal  parameter  class  for  excep- 
tional condition  control. 


Pequirement:  C3 

Specification  of  the  type,  ranie,  precision,  dimension, 
scale  and  format  of  parameters  will  be  optional  on  the 
formal  siae.  None  of  them  will  be  alterable  at  run  time. 


Optional  properties T 

Fixed  at  run  time T 


CS-4  totally  meets  this  reouirement. 


Requirement:  CR 

There  will  he  provision  for  variable  numbers  of  arou- 
ments,  out  in  such  cases  all  nut  a constant  number  of 
them  must  oe  of  the  same  type.  Whether  a routine  ran 
have  a number  of  arouments  must  he  determinable  from  its 
description  and  the  number  of  arqument.s  for  anv  call  will 
oe  determinaple  at  compile  time. 


Variable  number  of  arquments F 

All  but  constant  number  same  type F 

Number  fixed  at  compile  time F 


CS-4  does  not  support  procedures  with  a variable  number 
of  arauments.  Full  CS-4  does  provide  the  necessary 
mechanisms  for  this  requirement. 


D.  VARIABLES,  LltERALS  AND  CONST ANTS 


» 


Requirement:  Dl 

The  user  dill  have  the  anility  to  associate  constant 
values  of  any  tvoe  with  identifiers. 


CS-4  totally  meets  this  requirement. 


Requirement:  02 

The  lanouaqe  will  provide  a syntax  and  a consistent  in- 
terpretation for  literals  of  built-in  data  types.  Numer- 
ic literals  will  have  the  same  value  (within  the  speci- 
fied precision)  in  both  proqrams  and  data  (incut  or  out- 
put). 


Literals  of  built-in  data  types T 

Consistency  in  value T 


CS-4  totally  meets  this  requirement. 


Requirement:  03 

The  lanouaue  will  permit  the  user  to  specify  the  initial 
values  of  individual  variables  as  part  of  their  declara- 
tion. Such  variables  will  be  initialized  at  the  time  of 
their  apparent  allocation  (i.e.,  at  entrv  to  allocation 
scone).  There  will  be  no  default  initial  values. 


Declare  initial  values T 

Allocation  scone  initialization T 

No  default  values T 


CS-4  totally  meets  tnis  requirement. 


Requirement:  04 

The  source  lanauaqe  will  require  its  users  to  specify  in- 
dividually the  ranae  of  all  numeric  variables  and  the 
step  size  for  fixed  point  variables.  The  ranqe  specifi- 
cations will  be  interpreted  as  the  maximal  ranae  which 
must  he  supported  by  the  object  code.  Ranqe  and  step 
size  sneci £ icat ions  will  not  ne  interpreted  as  definina 
new  types. 


Ranae  specification  is  reouired  for  all  numeric  modes 
( sped  f let  aion  may  be  implicit). 

fixed  point  typed  data  is  not  supported  (see  note  on  re- 


■ r i r i - - ~i  ‘'initiiri!] 


*jc. , ' iiipwr  mu 


qu 1 rpment  A? ) . 


P e quirement:  05 

The  range  of  values  which  can  De  associated  with  a vari- 
able, array,  or  record  component  will  be  any  built-in 
type,  any  defined  tvoe  or  a contiguous  subseauence  of  any 
enumeration  type. 

CS-4  totally  meets  this  requirement. 


Peou i r ement : 06 

The  lamuaoe  will  provide  a pointer  mechanism  which  can 
be  used  to  build  data  with  snared  and/or  recursive  sub- 
structure. The  pointer  property  will  only  affect  the  use 
of  variables  (including  array  and  record  components)  of 
some  data  types.  Pointer  variables  will  oe  as  safe  in 
their  use  as  are  anv  other  variables. 

Shared/recursive  substructure  capability 1 

Var iable/record/ar ray  comoonenT  nanalino... T 

Typed  pointer  char  act  er  i s f ic T 

Allocation  never  wider  than  access 1 

The  CS-4  pointer  mechism  is  limited  to  dynamiclv  allocat- 
ed data  (data  allocated  in  HEAP  storage  via  the  ALLOCATE 
statement). 


K.  DEFINITION  FAC  I LIT  It  S 
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Requirement:  F 1 

The  user  of  toe  language  will  tie  able  to  define  new  data 
tyoes  and  onerations  within  his  programs. 

CS-4  totally  meets  this  requirement. 


Requirement:  F 2 

The  "use"  of  defined  t yoes  will  be  indistinguishable  from 
built-in  types . 

CS-4  totally  meets  this  requirement. 


Requirement:  FI 

Kach  orooram  component  will  be  defined  ir  the  base 
lanquaqe,  in  a library,  or  in  the  program.  There  will  be 
no  default  declarations. 

CS-4  totally  meets  this  requirement. 


Requirement:  F 4 

The  user  will  be  able,  within  the  source  lanquaqe,  to  ex- 
tend existing  operators  to  new  data  types. 


CS-4  totally  meets  this  requirement. 
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Requirement:  Fs 

Type  definitions  in  the  source  language  will  permit  de- 
finition of  noth  the  class  of  data  objects  comprising  the 
types  and  the  set  of  operations  applicable  to  that  class. 
A defined  tyoe  will  not  automatically  inherit  the  opera- 
tions of  the  data  with  which  it  is  represented. 


> 


CS-4  totally  meets  this  requirement. 


Requirement:  E6 

The  data  objects  comprisina  a defined  type  will  be  defin- 
able nv  enumeration  of  their  literal  names,  as  Cartesian 
Droducts  of  existing  tvoes  Ci.e.,  as  array  and  record 
classes),  oy  discriminated  union  (i.e.,  as  the  union  of 


iisioint.  tyoes ) and  as  the  power  set  of  an  enumeration 
tvoe.  These  definitions  will  be  processed  entirely  at 
comni  le  time. 


Kmjmerat  ion T 

Cartesian  products t 

Discriminated  union T 


Power  set  of  enumeration  type....T 

CS-4  contains  extensive  data  type  definition  facilities. 
Enumeration  and  power  set  definition  can  ne  applied 
throuah  tne  use  of  the  RAhCK  qualifier. 


Requirement:  E 7 

Tyoe  definitions  by  free  union  (i.e.,  union  of  non- 
disloint  types)  and  subsettinn  are  not  desired. 


Does  not  nermit  free  unions T 

Does  not  permit  subsettino T 


CS-4  totally  meets  this  requirement. 


Requirement:  E 8 

vhen  defining  a type,  the  user  will  ne  able  to  specify 
the  i ni t i a 1 i zat i on  and  finalization  procedures  for  the 
type  and  tne  actions  to  be  taken  at  the  time  of  alloca- 
tion and  deallocation  of  variables  of  that  tvne. 

1 


CS-4  totally  meets  this  requirement 


F.  SCOPES  AMO  LI  HR ARIFS 


Requirement:  Fi 

The  language  will  allow  the  user  to  distinguish  between 
scoDe  of  allocation  and  scope  of  access. 

CS-4  total  lv  -neet-S  this  requirement. 


Requirement:  f 2 

The  ability  to  limit  the  access  to  seoarately  defined 
structures  will  be  available  both  where  the  structure  is 
defined  and  where  it  is  used.  It  will  be  DOssiDle  to  as- 
sociate new  local  names  with  separately  defined  program 
components . 

CS-4  totally  meets  this  requirement. 


Requirement:  F3 

c 

The  scope  of  identifiers  will  be  wholly  determined  at 
compile  time. 

CS-4  totally  meets  this  requirement. 


Requirement:  F4 

A variety  of  application-oriented  data  and  operations 
will  be  available  in  libraries  and  easily  accesible  in 
the  l anquage . 

---u 


Variety  of  data  and  operations, 
Easilv  accesible 


The  compostion  and  extent  of  application  oriented  li- 
oraries  is  not  defined  for  CS-4  at  this  time.  The  crea- 
tion of  such  libraries  should  present  no  oreat  problems 
at  the  time  CS-4  is  finally  implemented. 


Reou  i rement : P’S 


Program  components  not  defined  within  the  current  program 
and  not  in  the  base  lanouage  will  be  maintained  in  com- 
pile time  accessible  libraries.  The  libraries  will  be 
capable  of  holding  anvfhinq  definable  in  the  lanouaoe  and 
will  not  exclude  routines  whose  bodies  are  written  in 
othpr  source  languages. 

---li--- 
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They  \ 

will  be  capable  of  holding  anything  definable  in  the  \ 
language,  and  it  will  he  possible  to  associate  them  with 
any  level  of  programming  activity  from  systems  through 
orolects  to  individual  nroorams.  There  will  he  many  spe- 
cialized comoools  or  libraries  any  user  specified  subset 
of  which  is  immediately  accessible  from  a given  program. 


Libraries  and  compools  indistinguishable ..tl 

Hold  anything  definable  in  language U 

Many  levels  of  access U 

Many  specialized  subsets U 


See  note  on  requirement  F4. 


Requirement:  F7 

The  source  lanquaoe  will  contain  standard  machine  in- 
dependent interfaces  to  machine  dependent  capabilities, 
including  oerinneral  equipment  and  special  hardware. 

The  MSTRUCTUPF  mode  of  CS-4  satisfies  this  requirement. 


ftccesible  at  compile  time _ 

Other  source  language  routines U 

See  note  on  requirement  F4. 

Requirement:  Fb 

Libraries  and  Compools  will  be  indistinguishable, 


G.  CONTROL  STPUCTUPRS 


Requirement:  G1 

The  1 anouaqe  will  provide  structured  control  mechanisms 
tor  sequential,  conditional,  iterative,  and  recursive 
control.  It  will  also  provide  control  structures  for 
(pseudo)  parallel  processino,  exception  nandllno  and 
asynchronous  interrupt  handlinq. 

p 


Sequent  i a 1 control T 

Conditional  control T 

Iteration T 

Recursion F 

Parallel  processino F 

Rxcention  handlinq T 

Asvncronous  interrupts T 


CS-4  provides  all  of  the  standard  sturctured  control 
mechanises  with  the  exception  of  parallel  processing  and 
recursion.  Full  cs-4  provides  for  the  inclusion  of  con- 
trol structures  for  both  parallel  processing  and  recur- 
sion. 


Reauirement:  G? 

The  source  language  win  provide  a "go  to"  operation  ap- 
plicable to  program  labels  within  its  most  local  scone  of 
definition. 


CS-4  totally  meets  this  requirement. 


Requirement:  G1) 

Tne  conditional  control  structures  will  be  fully  parti- 
tioned and  will  permit  selection  amona  alternative  compu- 
tations based  on  the  value  of  a Boolean  expression,  on 
the  subtvne  of  a value  from  a discriminated  union,  or  on 
a computed  choice  aTona  lareled  alternatives. 


Based  on  boolean  expression.... T 

Based  on  type  from  discriminated  union T 

Based  on  computed  choice T 


CS-4  totallv  meets  this  requirement. 


Requirement:  G4 


The  iterative  control  structure  will  permit  tne  termina 
tion  condition  to  aonear  anywhere  in  the  loon,  will  re 
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quire  control  variaoles  to  be  local  to  the  Iterative  con- 
trol, will  allow  entry  only  at  the  head  of  the  loop,  and 
will  not  Impose  excessive  overhead  in  clarity  or  run  the 
execution  costs  tor  common  soecial  case  termination  con- 
ditions (e.q,  fixed  number  of  iteration  or  elements  of  an 
arrav  exhausted). 


Termination  anywhere  in  loop T 

Local  control  variables... F 

Entry  at  loop  head  only T 

Efficient  and  clear  simple  cases T 

Control  value  available  at  termination T 


Tn  CS-4  iterative  control  variables  are  not  treated  soe- 
cial ly. 


Requirement:  Gb 

Recursive  as  well  as  nonrecursive  routines  will  be  avail- 
able in  the  source  lanquaqe.  It  will  not  be  possible  to 
define  procedures  within  the  body  of  a recursive  pro- 
cedure. 


Recursive  and  nonrecursive  routines F 

Explicitly  specify  recursive  routines F 

No  nested  recursive  procedures F 


CS-4  does  not  provide  for  recursion  in  any  form.  Full 
CS-4  supplies  facilities  for  recursive  routines  which 
meet  or  exceed  requirement  GS. 


Peauirement:  Gb 

Tne  source  lamuaoe  will  Provide  a parallel  processinq 
capability.  This  capability  should  incluoe  the  ability 
to  create  and  terminate  (possible  pseudo)  parallel 
processes  and  for  these  processes  to  qain  exclusive  use 
of  resources  durinq  specified  portions  of  their  execu- 
tion. 


CS-4  has  no  parallel  processing  facilities.  full 
CS- 1 , however , provides  extensive  parallel  processinq 
mechanisns  which  meet  or  exceed  requirement  Gb. 


Requirement:  G7 

Tne  exception  handlim  control  structure  will  permit  the 
user  to  cause  transfer  of  control  and  data  for  any  error 
or  exception  situation  which  miqht.  occur  in  a prooram. 

---T 


CS-4  totally  'fleets  this  requi rerr.er.t 
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Reauirement:  G8 


There  will  be  source  language  features  which  permit  de lay 
on  anv  control  Dath  until  some  specified  time  or  situa- 
tion has  occurred,  which  oermit  soeci f icat ion  of  the  re- 
lative Driorities  among  parallel  control  oaths,  which 
give  access  to  real  time  ciocKs,  which  permit  asynchro- 
nous hardware  interrupts  to  be  treated  as  any  other  ex- 
ception situation. 

---F- — 

The  necessary  features  to  satisfy  this  reaui rement  are 
contained  in  "the  CS-4  Operating  System  Interface"  or 
■within  full  CS-4.  Basic  CS-4  does  not  include  the  re- 
guired  mechanisms. 


H.  SYNTAX  AND  COMMENT  CONVENTIONS 


Renuirement:  HI 

The  source  lamuaae  will  toe  free  format  witn  an  explicit 
statement  separator,  will  allow  the  use  of  mnemon i ca 1 1 v 
significant  identifiers,  will  he  cased  on  conventional 
forms,  will  nave  a simple  uniform  and  easily  parseo  aram- 
mar,  will  not  provide  unioue  notations  for  special  cases 
will  not  permit  abbreviation  of  Identifiers  or  Key  words, 
and  will  be  syntactically  unambiguous. 
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Free  format  with  statement  separator T 

Mnemonicallv  sinnificant  identifiers T 

Conventional  forms T 

Simple  uniform  arammar T 

No  special  case  notations T 

No  abbreviation  of  keywords  or  identifiers....! 
Unambiguous  grammar .T 

Altnouoh  CS-4  syntax  is  quite  extensive,  it;  seems  to  be 
highly  readable. 


Requirement:  H 2 

The  user  will  not  be  able  to  modify  the  source  lanauaoe 
syntax.  Spec i f leal  1 y , he  will  not  be  able  to  modify 
operator  hierarchies,  introduce  new  precedence  rules,  de- 
fine new  key  word  forms  or  define  new  infix  operator  pre- 
cedence . 

CS-4  totally  meets  this  requirement. 


Requirement:  H3 

The  svntax  of  source  language  programs  will  te  comrosable 
from  a character  set  suitable  for  publication  purposes, 
nut  no  feature  of  the  language  will  be  inaccessible  using 
tne  f>4  cnaracter  ASCII  subset. 

p 

CS-4  uses  the  94  printing  characters  of  12P  character  re- 
viseo  1JS  AC  f I character  set  (USA  standard  X3. 4-1968). 
modification  of  the  lanauaqe  to  accert  tne  64  character 
subset  should  be  trivial. 


Requirement:  H4 

The  language  definition  will  provide  the  formation  rules 
for  identifiers  and  literals.  These  will  Include 
literals  for  numbers  and  character  strings  and  a break 
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character  for  use  internal  to  identifiers  and  literals. 

T 


Literals  tor  numbers T 

Character  strirns T 

Break  character T 


CS-4  totaliv  meets  this  requirement. 


Requirement:  hs 


There  will  be  no  continuation  of  lexical  units  across 
lines,  but  there  will  be  a way  to  include  object  charac- 
ters such  as  end-of-line  in  literal  strinqs. 

CS-4  lexical  units  may  not.  be  continued  across  lines,  at 
oresent  there  is  no  provision  for  inclusion  of  object 
characters  in  literal  strinqs.  Tne  addition  of  this 
feature  should  be  trivial. 


Requirement:  H b 


Key  words  will  be  reserved,  will  be  very  few  in  number, 
will  be  informative,  and  will  not  be  usable  in  contexts 
where  an  identifier  can  be  used. 

qiven  the  extent  of  the  lanquaoe,  keywords  are  acceptably 
fe*  in  number  and  all  are  reserved. 


v. 

Requirement:  H7 
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The  source  lanquaqe  will  have  a sirnle  uniform  comment 
convention.  Comments  will  be  easily  d i st inqu i shat  le  from 
code,  will  be  introduced  bv  a slnqle  (or  possibly  two} 
lanauaqe  defined  characters,  *111  permit  any  combination 
of  characters  to  aroear,  will  be  able  to  appear  anywhere 
reasonable  in  oroqrams,  will  automat ical ly  terminate  at 
end-of-line  if  not  otherwise  terminated,  and  will  not 
prohibit  automatic  reformattinq  of  proqrams. 


Slnqle  comment  convention.. .....F 

Di  st  iron  1 shao  1 e from  code T 

Introduced  by  one  or  two  cnaracters T 

Contain  any  charcter. p 

ADDear  anvwnere  reasonable T 

Terminate  at  end  of  line P 

Mot  prohibit  reformattinq T 


CS-4  contains  two  comment  conventions: 

(1)  The  nrecent  character  (%)  may  be  used  to  indicate  a comment 
terminates  on  end  of  line. 

(2)  The  bracket  rotation  ( ( ,)  ) form  reauires  both  comment  ; 
delimiters  to  he  present,  termination  is  not  automatic  on  end  of  line.'; 


-also  each  comment  delimiter  within  the  comment  strim  must  be  matched. 


1 


Requirement : ms 

The  lanquaie  will  not  Dermit  unnatched  parentheses  of  any 
Kind. 

CS- \ totally  meets  this  requirement. 


Requirement:  H9 

There  will  be  a uniform  referent  notation. 
CS- 4 totally  meets  this  requirement. 


Requirement:  HlO 

hi o lanquaqe  defined  symbols  aopearind  in  the  same  context 
will  have  essentially  different  meaninqs. 

T 

CS- 4 totally  meets  this  requirement. 


I.  DEFAULTS , 


CONDITIONAL  COMPILATION,  AND  TANGUACF  PFSTRTCTIONS 


Penu i recent:  II 

There  will  he  no  defaults  in  programs  which  affect  the 
oronram  Ionic.  I'hat  is,  decisions  wnich  affect  oronram 
Ionic  will  ne  made  either  irrevocably  when  the  lanquaqe 
is  defined  or  explicitly  in  each  pronram. 


CS-4  totally  meets  this  requirement. 


Penn i rement : 12  ^ 

Defaults  will  oe  provided  tor  special  capabilities  af- 
fection only  object  representation  and  other  properties 
which  the  pronrammer  does  not  Know  or  care  about.  Such 
defaults  will  always  mean  that  the  pronrammer  does  not 
care  which  choice  is  made.  The  pronrammer  will  be  able 
to  override  these  defaults  when  necessary. 

i — T— 

CS-4  tota  1 1 y,  meet s this  requirement. 


Requirement : 1 1 t 

The  user  will  be  able  to  associate  compile  time  variables 
with  programs.  These  will  include  variables  which  speci- 
fy the  oblect  computer  model  and  other  aspects  of  tne  ob- 
ject machine  configuration. 

CS-4  does  not  include  provisions  tor  a special  class  of 
"compile  time"  variables.  Instead  any  variable  who's 
value  is  Known  at  compile  time  (via  initialization)  may 
be  utilized  in  compile  time  functions.  Specification  of 
the  oblect  machine  configuration  is  accomplished  through 
the  use  of  ^STRUCTURE  specifications. 


Requirement : 1 4 

The  source  language  will  permit  the  use  of  conditional 
statements  (e.q.,  case  statements)  dependent  on  the  ob- 
ject environment  and  other  compile  time  variables.  In 
such  cases  the  conditional  will  be  evaluated  at  compile 
time  and  only  the  selected  path  will  be  compiled. 

c p 

CS-4  provides  for  compile  time  evaluation  of  expressions 
composed  of  Known  values.  There  are, however,  no  mechan- 
isms whereby  selective  compilation  may  occur.  Full  CS-4 
supplies  the  necessary  compile  time  control  structures 
for  meeting  this  requirement. 


Requirement:  IS 


The  source  lanquaae  will  contain  a simple  clearly  iden- 
tifiable base  or  Kernel  which  houses  all  the  power  of  the 
lanauaqe.  To  the  extent  possible,  the  base  will  be 
minimal  with  each  feature  Providing  a sinqle  unique  capa- 
bility not  otherwise  duplicated  in  tne  base.  The  choice 
of  the  base  will  not  detract  from  the  efficiency,  safety, 
or  under s t andao i i i t y of  the  lanauaqe. 


CS-4  is  based  upon  the  Kernel  lanouaae  K|. s-K . 


Requirement : 16 

Lanauaqe  restrictions  which  are  dependent  only  or  the 
translator  and  not  on  the  object  machine  will  be  speci- 
fied explicitly  in  the  lanauaqe  definition. 


CS-4  totally  meets  this  requirement. 


Requ i rexent : I 7 

Lanquaae  restrictions  which  are  inherently  dependent  only 
on  the  object.  environment  will  not  be  built  into  the 
lanquaqe  definition  or  any  translator. 

T 


CS-4  totally  meets  this  requirement. 


. 


time.  Certainly  the  CS-4  laniu-ne  designers  desire  effi- 
ciency of  object  code.  Such  a pr  oper  t y , ho  wever  , cannot  be 
defined  in  the  design  of  a language  directed  at  a number 
of  computers  possesing  a variety  of  architectures. 


Requirement:  1? 


Any  optimizations  nerformed  by  the  translator  ’*  i 11  not 
change  tne  effect  of  toe  nroaram. 

CS-1  meets  this  requirement  in  the  sense  that  it  is  a 
stated  desion  goal  of  tne  language.  Tn  reality  the 
determination  of  this  question  would  be  somewhat  depen- 
dant upon  the  specific  implementation  of  a given  CS-4 
trans lator . 


Requirement:  J 3 

The  source  language  will  provide  encapsulated  access  to 
machine  dependent  hardware  facilities  including  machine 
language  code  insertions. 

CS-1  totally  meets  this  r eau i rement . 


Requirement:  J4  It  will  be  possible  within  the  source 
language  to  specify  the  object  presentation  of  composite 
data  structures.  These  descriptions  will  be  oDtional  and 
encaoslated  and  will  distinct  fron  the  logical  descrip- 
tion. The  user  will  be  able  to  specify  the  time/space 
trade-off  to  the  translator.  If  not  specified,  the  ob- 
ject representation  will  be  optimal  as  determined  by  the 
translator . 

p 


Specify  oblect  presentation T 

Specify  time/space  tradeoff U 


Time/space  tradeoff  spec t f i cat  ion  is  not  addressed  in  the 
available  documentation. 


Reouirement:  IS 


The  nroqrammer  will  he  able  to  speciiy  whether  calls  on  a 
routine  are  to  have  an  open  or  closed  imp i ement at  1 on . An 
open  and  closed  routine  of  the  same  description  will  have 
identical  semantics. 


CS-4  K VALUATION  SUMMARY 


This  section  presents  a summary  of  the  evaluation  of 
basic  CS-4  against.  the  Don  "Tinman"  r equ  i rement  s . Tfie 
malor  strengths  and  weaknesses  of  the  language  in  rela- 
tion to  the  requirements  will  be  detailed  and  appraisal 
given  as  to  the  overall  de s i r eah i l i t y of  utllizina  CS-4 
as  a base  language  tor  future  HOL  deve looement . 

The  maior  strengths  of  CS-4  are: 

Stxaaa  daXa  Lvaiaa.  All  data  modes  in  CS-4  are  rioidly 
typed  as  to  data  character  i st ics  and  access.  In  addition 
type  checkin':  is  enforced  during  runtime  as  well  as  com- 
pile time,  such  a trait  significantly  increases  the  pos- 
sibilities of  producing  reliable  programs. 
fclxLensxiie  and  XnaXcaX  caatraX  sXxucXuxes.  CS-4  provides  a 
concise  set  of  control  mechanisms  sufficient  for  struc- 
tured program  construction  w i t n o u t tieing  overly  ela- 
borate. 

LxXaaSiXaaXXXXXic.  CS-4  contains  features  for  the  defini- 
tion of  new  data  modes  and  for  tne  utilization  of  these 
extended  modes  in  a straightforward  manner. 

XacbXaa  Xabaaendauce..  CS-4  is  a highly  machine  indepen- 
dant language  with  a set  of  facilities  for  mating  tne 
1 anauaoe  to  a specific  machine.  Whether  the  facilities 
provided  are  sufficient  for  a tight  tit  is  an  open  Ques- 
tion that  can  only  be  resolved  by  imp ] ement a t i on  . 

XeuaXa  aX  uaaaa.  CS-4  Provides  facilities  whereby  the 
language  may  be  used  on  several  levels.  This  multi- 
leveling includes  tne  enab 1 inq/di sab  1 ina  of  GOTH 

usage , run-time  range  checking  and  other  language 
features.  Tnis  tyne  of  usage  scheme  would  seen  well 
suited  to  tne  stepped  developement  of  both  programs  and 
Drorammer  skill. 

The  major  weaknesses  of  CS-4  are: 

Lact  ox  <a  XXxea-uaXoX  data  made.  The  CS-4  designers  ra- 
tionalized the  exclusion  of  fixed-point  as  being  both  un- 
necessary due  to  the  droo  in  cost  of  floating  point 
nardware  and  inefficient  because  of  the  necessity  of 
shifting  for  decimal  point  alinement  in  arithmetic  opera- 
tions. Trie  validity  of  these  arguments  woulo  seen  to  hold 
for  medium  to  large  scale  systems  while  becoming  suspect 
when  applied  to  most  mini  systems. 

Xacx  oX  1/J  XacXXXXXes  Xu  too  base  Xaoouaae.  uisic  CS-4 
contains  no  I/O  facility  definitions.  Instead  I/O  mechan- 
isms are  dpfined  within  the  context  of  "The  CS-4  Operat- 
ing System  Interface",  a set  of  procedure  calls  which 
define, in  addition  to  I/O  ser v ices  , par al  1 e 1 nrocessino 
constructs  and  other  miscelaneous  operating  system  func- 
tions. hmnedded  within  this  "interface"  is  the  defini- 
tion of  a comriete  file  system  structure.  The  inclusion 
of  such  a spec i f leaf  ion  as  part  of  the  basic  language 
would  be  unacceptable  as  being  too  extensive  ( the 
language  designers  have  In  effect  defined  an  oneratina 
system  for  tneir  language). 


LAsfcMR  irwrimr  r«-j r*  * . 


* 


Cd-i  is.  aa  uaiaulficfiated  laaauaafi.  This  might  not  be 
fairly  considered  a defect  in  relation  to  "Tinman" 
r enu i rement s . nowe ver  in  relation  to  tne  overall  consis- 
tency of  tne  language  it  would  seen  that  much  benlfit 
could  De  qainea  by  the  feedback  resultin'!  from  a trail 
implementation. 

do  x.ficux.uiufi  ax.acedux.ei.  CS-4  procedures  havp  no  capabil- 
ity for  recursion.  This  detect  has  been  corrected  in  full 
CS-4. 

da  uax.fillfil  ax.ace.is.iaa  caaediliU*.  Parallel  processing 
constructs  .like  the  I/Q  mechanisms  of  CS-4,  are  embedded 
within  tne  "Qperatinn  System  Interface". 

Lacs  oi  caocise  caauexsiaa  ax.acfidux.es.  CS-4  documentation 
is  ouite  specific  tnat  no  implicit  conversion  between 
unlike  data  modes  will  occur.  t-o  explicit  conversion 
mecnanisms  are  spepifieo  however. 


In  summary  CS-4  is  an  extens  i ve , near  state-of-the-art 
language  which  contains  a nreat  numoer  of  the  traits  out- 
lined in  tne  "Tinman"  r enu i r ement s . The  extended  version 
[ of  the  language, ful 1 CS-4 , conta i ns  nearly  all  of  the 

necessary  features  for  meeting  the  requirements.  On  the 
negative  side  CS-4  has  several  serious  defects, all  of 
, which  seem  to  be  outgrowths  of  the  fluid  nature  of  the 

language.  If  this  lack  of  consistarcy  can  ne 
cor r ec t e i , ei ther  through  feedback  from  trail  implementa- 
tions nr  a more  unified  language  design  effort,  CS-4 
would  maKe  a tine  choice  for  a hoi.  baseline. 


| . 


* j 


* 


f: 

$ 


ar*>? 


EVALUATION  OF 


TACPOL 


Prepared  by 

RLG  Associates,  Inc. 
11250  Roger  Bacon  Drive 
Suite  16 

Reston,  Virginia  22090 


December  3,  1976 


This  report  presents  an  evaluation  of  the  TACPOL  language 
with  the  requirements  listed  in  the  "TINMAN".  CDDD  Require- 
ments for  Hiah  Order  Computer  Programming  Languages,  "TIN- 
MAN" - 1 warch  1 976,  Section  IV).  For  purposes  of  compari- 
son TACPOL  is  considered  to  he  defined  nv: 


CPfF  1 SPFC  l F I C AT  TON  FOP  COMP  1 1 FP / ASSFMHI  KP  FOP  FIPF 
DIRFCT 1 09  SYSTFM,  Spec.  Mo.  EL-CG-000 1 3082C , hoc.  Mo. 
595909-60  OC , Volume  1 of  2,  Apoendi  x 10  (FORMAL  OFF  I M - 
TIOM  OF  T/ACPOI.) 


There  are  78  language  requirements  listed  in  section  4 of 
the  "TINMAN".  This  report  compares  TACPOL  w i t t each  inoivi- 
dual  requirement.  A summary  of  the  degree  to  which  the 
lamuaae  satisfies  each  requirement  is  presented. 

The  oaraaraoh  number  of  each  "tinman"  requirement  is  includ- 
ed as  the  leadino  section  tor  each  requirement  evaluation. 

Symbols  Placed  beside  each  individual  requirement  indicate 
the  deoree  to  which  the  language  meets  the  requirement.  The 
svmools  and  their  meaning  are  as  follows: 

T - Totally  meets  requirement 

P - Partially  meets  requirement 

F - Does  not.  meet  requirement 

IJ  - Unknown  from  available  document  at  ion 

A summary  of  the  evaluation  is  included  as  the  last  section 
of  this  report.  Merits  and  failures  of  the  lanauane  as  it 
currently  is  defined  are  discussed.  Also  discussed  are  the 
potential  language  modifications  that  can  oe  made  to  support 
00D  "TINMAN"  requirements. 


l < i<"  ii  in  MMnt  i ~ri  . sxrr»s ^ > - 


A.  DATA  AND  TYPES 


Requirement:  A1 

Tne  lanouaae  will  be  tyoed.  The  type  (or  mode)  of  all  vari- 
ables, components  of  romnosite  data  structures,  expressions, 
operations,  and  Darameters  will  be  determinable  at  compile- 
time  and  unalterable  at  run-time.  The  lanquaoe  will  require 
that  the  t.yoe  of  each  variable  and  component  of  composite 
data  structures  be  explicitly  specified  in  the  source  nro- 
oram . 

- — ^ 


TACPOL  is  a stronqlv  typed  lanauaoe.  All  quantities  (units 
of  storaoe  which  hold  a value)  must  be  one  of  four  possible 
types:  short  numeric:  lorn  numeric;  character  strina;  bit 

strinq. 

Quantity  types  cannot  be  altered  at  run-time  but  value 
conversions  can  be  marie  by  means  of  several  "intrinsic  pro- 
cedures" (explicit  conversion  functions  which  may  be  user)  in 
the  body  of  a TACPOL  prooram  and  which  have  meaninq  indepen- 
dent of  the  definitions  oiven  by  the  proq rammer).  These 

procedures  (listed  below)  make  appropriate  conversions  on 
the  value  of  the  aroument  of  the  procedure. 

SHORT  (X)  1 onq  numeric  to  snort  numeric,  character 

strinq  to  snort  numeric,  or  bit  strirn  to 
snort  numeric  (specific  conversion  selected 
depends  on  compile-time  of  X) 

LONG  (X)  short  numeric  to  lonq  numeric,  character 

strino  to  lonq  numeric,  or  bit  strino  to  lono 
numer  ic 

CHAR  (X)  short  numeric  to  character  strino,  lonq 

numeric  to  character  strina,  bit  strino  to 
character  strina 

HIT  (X)  short  numeric  to  bit  strinq,  Iona  numeric  to  . 

bit.  strina,  or  character  strina  to  bit  strinq 

TACPOL  does  suooort  a cell  structure  which.  is  desianed  to 
permit  an  equivalence  of  storane  usaqe  (i.e.,  overlay)  at 
run-time.  This  is  used  orinciDally  to  buffer  1/0  records  of 
different  formats.  Denendinq  on  the  run-time  checXino 
available  (undefined  in  TACPOL),  it  miqht  be  possible  to 


i 


aeneous  type)  'is  type  venerators. 


Inteaer  P 

F ixed  Point P 

Float i n c?  Point T 

Character  string  . . . . T 

Boolean  T 

Arrays  T 

Records p 


TACPhl  supports  the  four  data  types  described  in  At.  in  tne 
case  of  numerics,  TACPOL,  includes  the  ability  to  state  pre- 
cision (number  of  bits  representina  the  .most  sionificant 
oart  of  the  value!  and  scale  (where  to  Place  the  binary 
point,).  Short  numeric  permits  a precision  of  from  1 to  31 
bits;  Iona  numeric  from  3?  to  f>2  bits.  The  scale  must  be 
between  -127  and  +127.  Operations  on  numerics  take  into  ac- 
count the  precision  and  scale  of  each  operand. 

Althouah  all  numoers  are  stored  internally  in  one  word  (32 
bits)  or  two  word  (f>4  bit)  quantities  with  the  appropriate 
scale  factors,  the  proqrammer  may  code  number  values  as  in- 
tegers, fixed  point,  or  floating  point,  and  they  will  be 
treated  properly  both  on  input  and  on  output. 

TACPOL  also  provides  arrays  (up  to  3 dimensions)  as  quantity 
structures  which  mav  be  declared  and  desianated. 

The  concent  of  record  is  well  understood  in  tacpol,  althouah 
a strono  distinction  is  made  between  an  externally  recorded 
record  (without  much  detail)  and  the  well  defined  or  tyneri 
quantities  in  main  memory  from/to  which  records  are 
written/read  (normally  cells). 


Requirement:  * 3 


The  source  lanauaqe  will  reauire  qlonal  (to  a score)  specif- 
ication of  the  precision  for  floating  point  arithmetic  and 
will  permit  precision  spec!  1 icat  ion  for  individual  vari- 
ables. This  soec i f icat ion  will  he  interpreted  as  the  m*x- 
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imum  precision  required  by  the  prooram  logic  and  the  minimum 
precision  to  be  subported  bv  tne  oblect  code. 

- - - p --- 

As  discussed  in  A?,  TACPOL  does  support  precision  specifica- 


tion on  individual  quantities  but  not  anv  sort  of  global 
scooina  of  precision  requirements. 

All  operations  must  take  into  account  tne  individual  preci- 
sion specifications  of  each  operand. 


In  terms  of  hardware  independence,  TACPOL  does  rot  specify  a 
particular  machine,  but  it  seems  strongly  oriented  toward 
machines  with  fl-nit  bytes,  32-bit  words,  whose  Internal 
character  set  is  H-level  ASCII. 


I 


Global  scorim  of  precision  could  be  added  to  TArPOL  without 
much  difficulty,  throuoh  the  addition  of  new  syntax. 


Requirement:  A4 

Fixed  point  numbers  will  be  treated  as  exact  ouantities 
which  have  a rarne  and  a fractional  step  size  which  are 
determined  nv  the  user  at  comDi le-t ime.  Scale  factor 
manaaement  will  be  done  by  tne  compiler. 


within  the  limits  of  available  numeric  precision,  TACPOL 
fully  supDorts  the  scaled  inteoer  feature. 


Reouirement:  AS 

Character  sets  will  be  treated  as  anv  other  enumeration 
type . 

TACPOL  does  not  support  the  definition  and  orderinq  of  char- 
acters by  the  source  prooram.  Characters  are  said  to  be  in 
ASCII,  one  R-bit  byte  eauals  ASCII  character. 


Requirement:  Af> 

The  1 anquaqe  will  require  user  specif icat ion  of  the  number 
of  dimensions,  the  ranoe  of  subscript  values  for  each  dimen- 
sion, and  the  type  of  eacn  array  component.  The  number  of 
dimensions,  the  type  and  the  lower  subscript  bound  will  be 
determinable  at  comn i le-t  ime . The  upper  subscript  bound 
will  be  determinable  at  entry  to  tne  array  allocation  scope. 


Number  of  dimensions  fixed  at  comDile-time  . . . . T 

Tyne  fixed  at  comoile-time  T 

Lower  subscript  bound  fixed  at  complle-time  . . . T 
Subscripts  from  continuous  ranoe  .........  T 

Subscripts  from  enumeration  type . T 

Upper  subscript  pound  fixed  at  scone  entry  . . . . F 


TACPOL  supports  one,  two,  and  three  dimensional  arrays.  lne 
dimension  of  each  array  and  the  ranqe  of  each  subscript  is 
fixed  at  compile  (declaration)  time.  Subscript  ranoes  must 
fall  between  one  (always  tne  lower  bound)  and  N,  where  N is 
a number  explicitly  aiven  at  declaration  time.  N may  be  anv 
tvoe  of  numeric  auantity  which  yields  a value  not  less  than 
one.  A real  quantity  is  truncated  to  the  laroest  whole  in- 
t.eoer  not  urea  ter  than  its  value. 

At  desiqnation,  subscripts  may  be  an  expression  which  yields 


a short  numeric  value  within  the  declared  ranae  for  that 
subscript;  real  values  are  reduced  to  inteqers  as  above. 

Variable  uDoer  bounds  on  arrays  are  not  suonorted. 


Peouirement;  47 

The  lanquaoe  will  permit  recoros  to  have  alternative  struc- 
tures, each  of  which  is  fixed  at  compile-timp.  The  name  and 
tyoe  of  each  record  component  will  be  specified  tv  the  user 
at  compile-time. 


T4CP01,  places  no  restrictions  on  the  use  of  alternative 
structures  for  records.  t'ach  file  operation  in  TACPOl.  has 
associated  with  it  a fully  defined  buffer  data  structure, 
with  each  element  (scalar,  array,  table,  orour,  cell)  in  the 
structure  well  defined  and  tvDeo.  There  is  nothina  to 
prevent  the  Droarammer  from  reading  oi^g,  record  into  one 
structure  and  the  next  into  another. 

In  addition,  the  programmer  can  declare  a "cell"  (a  collec- 
tion of  sets  of  quantities)  all  of  which  are  allocated 
storaqe  in  common  (i.e.,  overlayeci).  Kach  set  of  quantities 
defines  a potentially  different  data  structure  for  a record. 
Fven  in  this  case,  full  tyne  check i no  is  done  as  the  surcell 
quantities  are  used. 


H 


OPERATIONS 


Requirement:  Bl 

Assianment  and  reference  operation  will  he  automat  i ca  1 1 y de- 
fined tor  all  data  tvoes  which  do  not  manaqe  their  data 
storaae.  The  assignment  ooeration  will  permit  anv  value  of  a 
oiven  tvoe  to  he  assigned  to  a variable,  array  or  record 
component  of  that  tvne  or  of  a union  tvoe  containing  that, 
tvoe.  Reference  will  retrieve  the  last  assioned  value. 

p 


Variable  declaration  tor  all  data  tyoes  . . . T 


Encapsulated  tvoe  declaration  ........T 

Array  or  record  declaration  T 

Array  assignment P 


TACPOf,  supports  referencing  of  quantities  and  assignment  of 
values  to  any  tyre  of  quantity  or  structure  which  can  be  de- 
clared. In  the  case  of  assignment,  multiple  quantities  can 
be  assioned  a single  value  in  one  assignment  operation,  out 
multiple  quantities  (e.q.,  arrays!  cannot  be  assigned  multi- 
ple values  in  a single  operation.  The  language  fully  sup- 
ports the  ability  to  reference  any  low  level  element  in  a 
complex  data  structure.  Reference  always  retrieves  the  last 
assigned  value. 


Requirement:  B2 

The  source  language  will  have  a built-in  operation  which  can 
be  used  to  compare  anv  two  data  ob-jects  (regardless  of  tvoe) 
for  identity. 


T ®CpOf,  supports  the  = relational  operator  which  can  be  used 
to  compare  anv  two  oblects  of  the  same  type  for  identity. 
All  four  TACpOL-recognized  types  are  supported. 

Numeric  values  are  compared  algebraical  lv,  character  string 
values  character-bv-character , left  to  right,  and  bit  string 
values  bit-by-Dit,  left  to  right. 


Requirement:  BI 

Relational  operations  will  be  automatically  defined  for 
numeric  data  and  all  types  defined  bv  enumeration. 

...  p ... 

TACPOL  supports  all  six  relational  ooerators  on  all  four 
tyres  which  it  recognizes. 


TACPOL,  does  not  recognize  unordered  sets 


r » 


Peouirement:  B 4 


The  built-in  arithmetic  operations  will  include:  addition, 
subtraction,  mu  1 1 iDl icat ion , division  (with  a real  result), 
exponentiation,  inteoer  division  (with  inteaer  or  fixed 
point  arguments  and  remainder),  and  neoation. 


Addition  T 

Subtraction  T 

Multiplication  T 

Division  (with  real  result)  . . T 

f'eoa t ion T 

Exponentiation  T 


Division  with  remainder  . . . . P 
r ACPOL  supports  all  of  these  operations. 

All  except  for  division  with  remainder  are  available  in  sin- 
dle  syntactical  operators.  In  order  to  do  division  with 
remainder,  three  operators  are  needed: 

normal  real  division  (A/B) 
intrinsic  procedure  TPUNC  (C) 

intrinsic  procedure  PEM  (D) 

The  first  two  can  be  confined  to  oet  the  whole  dividend  of 
the  division  as  follows: 

DIV  = TPUNC  (A/H) 

The  remainder  is  obtained  as  follows: 

REMAINDER  = PEM  (A,  (3) 


Reouirement:  DS 


i 

i 
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Aritnmetic  and  assianment  operations  on  data  which  are 
within  the  rame  specifications  of  the  pro  a ram  will  never 
truncate  the  most  sionificant  diqits  of  a numeric  ouantitv. 
Truncation  and  roundino  will  always  be  on  the  least  sionifi- 
cant dibits  and  will  never  be  implicit  for  inteoers  and 
fixed  point  numbers.  Implicit,  roundino  beyond  the  specified 
precision  will  be  allowed  for  floatin'?  point  numbers. 


Roundino  taxes  place  in  T acpol  only  when  the  intrinsic  pro- 
cedure, POUND,  is  explicitly  called  by  the  oroarammer. 
Round  operates  only  on  the  least  siqnificant  part  of  the 
numeric  value. 

Truncation  can  be  explicitly  done  in  TACPOL  by  means  of  the 
intrinsic  procedure  TPIJNC,  which  operates  only  oh  the  least 
sionificant  nart  of  a numeric  value. 


Implicit  truncation  takes  olace  durinq  an  assianment  opera- 
tion when  the  defined  precision  of  quantity  beinq  assianed  a 
value  is  less  than  that  of  the  value  derived  from  the  as- 
siqnment  exDression.  Once  aqain,  only  the  least  sianificant 
Dart  of  the  numeric  value  is  affected. 

Roundina  of  tloatinq  point  numbers  takes  olace  only  when 
specifically  called  for.  The  implicit  default  is  trunca- 
tion. 


Requirement:  b6 

The  built-in  boolean  operators  V wi 1 1 include  "AND",  "OP", 


"NOT",  and  "NOR".  The  oper 
evaluated  in  short  circuit  mode 


ions  "AND"  and  "OP"  will  be 


— p — 


Short  circuit  "and" 
Short  circuit  "or" 

Mot 

Nor 


Shor  t -c  i r cu  i t mode  is  not  addressed:  in  the  7ACPOJ,  FORMAT  DE- 
FINITION. I 

Normal  and,  OR,  and  NOT  are  supported  bv  TACPOL. 

NOR  does  not  exist  as  an  explicit  syntactical  element, 
althouah  the  identical  effect  of  NOR  can  be  achieved  by 
means  of  the  intrinsic  procedure  BjboL  as  follows  (where  X 
and  Y are  the  bit  variables  beina/AORed,  and  the  bit  literal 
is  the  truth  table):  / 

/ 

BOOL  (X.Vi^loOO'H) 


Peouirement:  b-7' 


Tne^s-orarce  lanquaqe  will  permit  scalar  operations  and  as- 
^i'Snment  on  conformable  arrays  and  will  permit  data 
transfers  between  records  or  arrays  of  identical  looical 
st  r ucture . 


Assionment  netween  records  and  arrays  . 
Scalar  operations  on  arravs  


TACPOI,  supports  the  assianment  of  values  of  one  set  of  quan- 
tities to  a second  set  of  quantities  by  means  of  the  Intrin- 
sic procedure,  OVF  (X,Y).  Tnere  is  no  requirement  that  the 
two  structures  (e.q.»  arrays)  be  conformable;  the  lenoth  of 
the  shorter  of  the  two  determines  the  scone  of  the  opera- 
tion. 

The  FORMAL  DEFINITION  does  not  define  the  scope  or  nature  of 


t y dp  checKinu  in  the  vqve  procedure 


Scalar  operations  on  arrays  are  not  supported. 


Reauirement:  Rri 

There  will  be  no  implicit  type  conversions  biit  no  conversion 
ODeration  will  be  reauired  when  the  type  of  an  actual  param- 
eter is  a constituent  of  a union  type  which  is  the  formal 
parameter.  The  lanauane  will  provide  explicit  conversion 
operations  amonq  integer,  fixed  point  and  floating  roint  da- 
ta# between  tne  orlect  representation  of  numbers  and  their 
representations  as  characters,  and  between  fixed  point  scale 
factors . 


Explicit  conversions  P 

Mo  implicit,  conversions T 


Explicit  between  scale  factors  . . T 

TACPHL  supports  a full  ranae  of  type  conversions  (see  answer 
to  Henuirement  M),  for  the  types  it  recoanizes. 

Numeric  values  are  all  stored  internally  as  one  or  two  word 
binary  quantities  with  a scale  factor#  hence  numeric  opera- 
tions (within  short  or  within  Iona)  always  yield  numeric 
values.  The  reauirement  for  explicit  conversion  operations 
between  integer,  fixed  point,  and  floatim  point  internal 
data  j s undef ined. 

Mo  implicit  conversions  are  supported. 

Numeric  values  can  be  rescaled  (with  no  chanqe  in  precision) 
by  means  of  the  intrinsic  procedure,  SCALE. 


Requirement:  B9 

Explicit  conversion  operations  will  not  be  required  between 
numerical  ranqes.  There  will  be  a run-time  exception  condi- 
tion when  anv  intener  or  fixed  point  value  is  truncated. 


TACPni,  does  not  suonort  this  function. 


Requirement:  bio 

Tne  base  landuaqe  will  provide  operations  allowinu  oroarams 
to  interact  with  tiles,  channels  or  devices  includina  termi- 
nals. These  operations  will  permit  sendino  and  receivino 
both  data  and  control  information,  will  enable  rronrams  to 
dynamically  assijn  and  reassiqn  I/O  devices,  will  orovine 
user  control  for  exception  conditions,  and  will  not  he  in- 
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TACPOl,  provides  support  for  a variety  of  file  declarations 
and  file  orocessim  operations. 

In  TACPOl.,  files  are  named  and  declared  to  be  either  serial 
or  direct  (oy  Key),  partitioned  or  nonoar t i t i oned , with  con- 
current or  nonconcur  rent  I/O:  a file  is  onened  in  one  of 
three  modes  --  innut,  outDut,  UDdate. 

Defined  tile  ooerations  include:  OPEN,  CLOSE,  Rf-AD,  vPITK, 
WRITE  ENDFILE,  R E * R I T F , DELFTF  , SPACE,  PEwlMD,  IlhwIM).  hx* 
ceotion  condition  procpssi.m  on  eno-of-file,  invalid  record 
Key,  and  invalid  partition  Kev  is  supported. 

TACPOl,  does  not  consider  devices  or  channels  explicitly, 
only  files.  Assignment  and  reassi dnment  of  1/0  devices  is 
therefore  undefined. 


Requirement : H 1 1 

The  lanauaae  will  provide  operations  on  data  types  defined 
as  power  sets  of  enumeration  types  (see  F6).  These  opera- 
tions will  include  union,  intersection,  difference,  comple- 
ment, and  an  element  predicate. 

Power  sets  are  not  defined  in  1ACPOI,. 


a r* 


C.  EXPRESSIONS  AND  PARAMETERS 


Requirement:  Cl 

Side  effects  which  ire  dependent  on  tne  evaluation  order 
amonq  the  arquments  of  an  expression  will  be  evaluated 
let  t-to-r iant . 


P 

•Numeric  expression  evaluation  within  TACPOL  is  done  accord- 
inn  to  the  followinq  precedence  order  of  operators  (from 
hiahest  to  lowest  precedence): 

infix  operators 
exponent iat ion 
multiolication/division 
addltion/suht rant  ion 

Boolean  expression  evaluation  is  done  accordinq  to  tne  f ol  - 
lowino  precedence: 

relational  operators 

NOT 

AMD 

OR 

conca  t ena  t i on 

within  anv  nrecedence  level  and  for  all  other  expressions, 
evaluation  is  performed  left  to  riant. 


Requirement:  C? 

which  parts  of  an  expression  constitute  the  operands  to  each 
operation,  within  that  expression,  should  he  obvious  to  the 
reader.  There  will  be  few  levels  of  ooerator  hjprarrhv  and 
they  will  be  widely  recoonized. 


Unambiquous  presentation  P 

Pew  precedence  levels  . . . . . . . T 
Reauire  explicit  parentheses  . . . . P 
No  user  defined  levels T 


TACPOf,  expression  presentation  is  relatively  straiqhtfor- 
ward,  with  the  usual  order  of  ooerator  oreceoence.  (See 
answer  to  Requirement  Cl.) 

Parenthesis  are  Permitted  to  reduce  ambiauitv  or  to  alter 
precedence,  but  are  not  required  except,  in  the  case  of  a re- 
lational suDPXpress ion  within  a Boolean  expression,  where 
the  entire  suoexoress  ion  must  be  enclosed  ir>  parentheses. 

Two  unusual  features  of  expression  notation  which  (in  this 
reader's  oDinion)  detract  from  overall  readability  of  ex- 
pression are  the  operators: 


( *♦ ) 


rind 


(♦ ) 

which  are  forms  of  exponentiation  and  mu  1 1 1 nl  irat  i on  , nut 
which  create  Iona  numeric  result  values  even  th.ouoh  the 
operands  are  of  the  short  numeric  type. 


[ ' 


Requirement:  C 1 

Expressions  of  a oiven  type  will  be  permitted  anywhere  in 
source  proarams  where  both  constants  and  references  to  vari- 
ables of  that  type  are  allowed. 

T AC  POL  meets  this  requirement  in  most  cases,  hut.  there  are 
some  minor  exceptions.  For  example,  in  the  destination  of  a 
substrina,  the  character  count  eraument  can  only  be  an  in- 
teaer  literal,  not  an  expression. 


Peau i rement : C4 

Constant  expressions  will  be  allowed  in  proarams  where  con- 
stants are  allowed,  and  constant  expressions  will  be 
evaluated  before  run-time. 

In  TACPOI,,  constant  expressions  can  replace  constants  any- 
where in  the  o roo ran,  excert  in  type  specifications,  arrav 
dec larat ions  , table  declarations,  value  dec larat i ons  , and  in 
certain  arguments  of  intrinsic  procedures.  These  exceptions 
are  not  reoar del  as  malor  shortcominos. 

The  evaluation  of  constant  expressions  petore  run-time  is 
oenerallv  undefined  in  the  EDEMA l DEFINITION. 


Requirement:  CS 

There  will  be  a consistent  set  of  rules  applicable  to  all 
parameters,  whether  t.hev  be  for  procedures,  tor  types  for 
exception  handlino,  for  parallel  processes,  for  declarat.i  on , 
or  for  built-in  operators.  There  will  be  no  special  opera- 
tions ( e . cj . , array  structurim)  applicable  only  to  parame- 
ter s . 

Consistency  in  parameter  rules  P 

No  special  parameter  operations  . . . . P 

Generally,  the  usaoe  of  parameters  appears  similar.  This  is 
expecially  true  in  simple  cases.  However,  as  the  user  taxes 
advantaae  of  the  more  sonhl st icat Pd  data  structures  In  TAC- 
POL  Ce.a.,  cells),  the  rules  for  parameter  usage  start  to 
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vary,  depending  on  what  is  needed  to  describe  the  structure 


Parallel  processing  is  not  defined.  Exception  handling  is 
defined  only  for  file  I/O  operations  ana  has  a syntax  all 
its  own . 


Reauirement : Cb 

Formal  and  actual  parameters  will  always  agree  ir  type.  The 
number  of  dimensions  for  array  parameters  will  be  determin- 
able at  compile-time.  The  size  and  suoscript  range  for  ar- 
ray parameters  need  not  be  determinable  at  comp i 1 e-t i me  , but 
can  be  passed  as  part  of  the  parameter. 


Dimensions  determined  at  compile-time  T 

Size  and  subscripts  can  be  passed F 


Tyne  agreement  for  actual  and  formal  parameters  . . . . T 

In  TACPOL,  the  dimensions  of  an  array  are  fully  determined 
at  comp i 1 e-t ime . This  includes  the  number,  size,  and  sub- 
script range. 

Size  and  subscript  ranae  cannot  be  passed  as  part  of  the 
parameter . 

Formal  and  actual  arguments  must  always  aaree  in  type. 


Reauirement:  C7 

There  will  be  four  classes  of  formal  parameters.  For  data 
there  will  be  those  which  act  as  constants  representing  the 
actual  parameter  value  at  time  ot  call,  and  those  which 
rename  the  actual  parameter  which  must  be  a variable.  In 
addition,  there  will  he  a formal  parameter  class  for  speci- 
fying the  control  action  when  exception  conditions  occur  and 
a class  for  orocedurp  parameters. 


P 


Parameter  constants  . 1 

Parameter  variables  T 

Fxceotion  conditions  p 


Procedure  parameters  T 

T ACPr)L  does  not  classify  formal  parameters  in  a universal 
sense  although  it  does  meet  some  of  the  renuirements  stated. 


When  formal  parameters  are  listed  in  a procedure  declara- 
tion, they  must  also  be  defined  by  an  impedded  parameter  de- 
claration whicn  classifies  each  as  a auantitv  (variable), 
value  (constant),  procedure  parameter,  or  point  (label). 

FxceDtions,  Der  se,  are  defined  onlv  for  file  I/O,  and  per- 
mit the  execution  of  a single  statement  in  the  event  that 


Y - 

!■  one  of  the  three  conditions  --  end-of-tile,  invalid  record 

key,  invalid  Dartition  key  --  are  wet.  The  structure  for 
E : this  is: 

ON  condition  THEN  statement  ELSE  statement 

other  run-time  conditions  which  can  be  checked  are  dtviae  bv 
zero,  fixed  overflow,  or  reference  to  a specified  identifier 
name.  The  desire  to  check  for  such  conditions  is  declared 
by  the  programmer.  Uoon  occurrence,  a "snap  procedure" 
(mentioned  out  undefined  in  TACPOL)  is  to  be  implicitly  in- 

Fvoked.  The  structure  of  an  interface  to  such  a procedure  is 

not  discussed  in  the  FORMAL  DEFINITION. 


Requirement:  C3 

Soeci f i cat i on  of  the  type,  range,  precision,  dimension, 
scale  and  format  of  parameters  will  he  optional  on  the  for- 
mal side.  None  of  them  will  be  alterable  at  run-time. 


B 


P 


Optional  properties  F 

Fixed  at  run-time T 


TACPOL  requires  that  all  formal  parameters  in  a declared 
procedure  be  themselves  declared  by  type,  precision,  dimen- 
sion, and  scale.  Ranae  is  implicit  in  short  and  lonq  scalar 
definition.  Format  is  not  addressed. 

Procedure  parameters  are  not  alterable  at  run-time. 


Requirement:  Ch 

There  will  be  provision  for  variable  numbers  of  arguments, 
but  in  such  cases  all  but  a constant  number  of  them  must  be 
of  the  same  type.  Whether  a routine  can  have  a number  of 
arguments  must  be  determinable  from  its  description  and  the 
number  of  arguments  for  any  call  will  be  determinable  at 
comoi le-time . 

p 


i/ariable  number  of  arguments F 

All  but  constant  number  same  type  . . F 
Number  fixed  at  compile-time  T 

TACPOL  does  not  support  variable  numbers  of  arouments. 

The  number  of  required  arouments  for  a procedure  is  fixed 
and  fully  determinable  at  compile-time. 


0 


V AR  I AROFS , LITEPALS  ano  constants 


Requirement:  01 

The  user  will  nave  the  ability  to  associate  constant  values 
of  any  type  with  identifiers. 


•-  T 


TACPfli,  provides  this  capability. 


Peauirement:  02 

The  lanauaae  will  provide  a syntax  and  a consistent  in- 
terpretation for  literals  of  built-in  data  types.  Numeric 
literals  will  have  the  same  value  (within  the  specified  pre- 
cision) in  noth  programs  and  data  (input  or  output). 

T 


literals  of  built-in  data  types  . . . T 
Consistency  in  value  T 

TACPOL  supports  this  capability. 


Requirement:  03 

The  lanauaae  will  permit  the  user  to  specify  the  initial 
values  of  individual  variables  as  oart  of  their  declaration. 
Such  variables  will  be  initialized  at  the  time  of  their  ap- 
parent allocation  (i.e.,  at  entry  to  allocation  scope). 
There  will  be  no  default  initial  values. 

Declare  initial  values  T 

Allocation  scooe  initialization  . . . . T 
No  default  values  T 

Using  the  value  ieclaration  statements,  the  user  can  declare 
the  initial  value  of  individual  variables.  If  he  does  not, 
no  default  values  are  assianed. 


Requirement:  04 

The  source  language  will  require  its  users  to  specify  indi- 
vidually the  range  of  all  numeric  variables  and  the  sten 
size  for  fixed  point  variables.  The  range  spec i f icat ions 
will  be  interpreted  as  the  maximal  range  which  must  be  sup- 
ported bv  the  oolect  code.  Range  and  step  size  specifica- 
tions will  not  oe  interpreted  as  defining  new  types. 
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TACPOL  requires  that  ail  numeric  type  variables  be  declared 
with  a ranqe  which  is  composed  of  a precision  (mandatory) 
and  a scalinq  (optional,  default  is  zero).  The  Interpreta- 
tion of  ranoe  is  for  both  comolle-time  and  oblect.  time 
values  (no  difference  Is  discussed). 

TACPOL  does  not  specifically  address  fixed  noint  variables 
or  their  sten  size. 

Within  ranqe  specification,  a precision  of  1 to  31  bits  im- 
plies short  numeric  tyre,  and  one  of  32  to  62  bits  implies 
lono  numeric  tvoe. 


Requirement:  05 

The  ranqe  of  values  which  can  be  associated  with  a variable, 
array,  or  record  component  will  be  any  built-in  tyre,  any 
defined  tyre  or  a continuous  subsequence  of  any  enumeration 
tyre . 

TACPOL  supports  this  feature,  except  tnat  user-defined  types 
and  ennumeration  types  are  not  defined. 


Pequ  i rement : Df> 

The  lanauaqe  will  provide  a pointer  mechanism  which  can  be 
used  to  build  data  with  shared  and/or  recursive  substruc- 
ture. The  pointer  property  will  only  affect  the  use  of 
variables  (includinq  array  and  record  components)  of  some 
data  tvnes.  Pointer  variables  will  oe  as  safe  in  their  use 
as  are  anv  other  variables. 

w w w p'  WWW 

Shared/recur s i ve  substructure  capability  . . . . F 
Var iable/record/ar ray  component  handlino  . . . . F 


Typed  pointer  characteristic  . . F 

Allocation  never  wider  than  access  F 


The  concept  of  a pointer  mechanism  (i.e.,  indirect  address- 
ina)  is  not  defined  in  the  formal  DEFINITION,  except  in  one 
location  (section  10.6.8,  Proper  Procedure  Des ionat 1 ons ) 
where  the  metal inoui st ic  element  < ADDP  DFSIG>  (one  aroument 
deslqnation)  is  defined  to  be  / < 13 1 T KXPR>/.  Wothinq  else  is 
mentioned  anywhere  else.  The  implication  Is  that  a hard  ad- 
dress can  be  Physically  built,  usinq  Boolean  operations. 
Tnere  appears  to  be  no  other  mechanism  in  the  lanauaoe  to 
dea 1 with  pointers. 
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E . DEHNITfON  FACILITIES 


Requirement:  El 

The  user  of  the  lanquaqe  will  he  able  to  define  new  da. a 
types  and  operations  within  his  proqrams. 


r AC  POL  cioes  not  support  these  features. 


Requirement:  E 2 

The  "use"  of  defined  tvnes  will  be  Indistinoui  shable  frorr 
built-in  types. 


Defined  tyoes  are  not  supported  in  TACPOL. 


Requirement:  El 

Each  rroqram  component  will  be  defined  in  the  base  lanquaqe, 
in  a library,  or  in  the  prooram.  There  will  be  no  default 
dec larat ions . 


p ... 


TACPOL  requires  that  many  proqram  components  he  defined  ex- 
plicitly. There  are  certain  exceptions,  however,  such  as: 

- Scale  factor  defaults  to  zero  on  numeric  quantities. 

- Precision  defaults  to  31  on  short  numeric  quanti- 
ties. 

- Data  alionment  defaults  to  PACKED  or  ALIGN'D, 
deoendina  on  declaration  type. 

- Eor  literals,  EDO  is  default,  and  scalino  defaults 
to  3.322  times  the  number  of  fractional  dibits  in 
the  literal. 

- In  suDStrino  operations,  the  optional  count  defaults 
to  one. 

- Several  f i 1 e-process inq  syntax  elements  can  default 
to  implicit  values. 

- All  intrinsic  procedures  have  default  values  and  im- 
plicit ranqe  restrictions. 

Tn  addition,  there  are  numerous  implicit  limits  enforced  bv 
T ACPOL , such  as: 
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- The  precision  of  numeric  values. 


The  maximum  lenqth  of  character  strings  (M2) 
bit  st  r inas  ( )2  ) . 


f 


The  maximum  value  of  the  step  variable  in  a DO 
statement  ( )?  , 7f>7  ) . 


Requirement:  K 4 

The  user  jv i 1 1 be  able,  within  the  source  lanouaqe,  to  extend 
existinn  operators  to  new  data  types. 

T AC POL  does  not  support  the  definition  of  new  types,  and 
hence  not  the  extension  of  existinq  operators  of  these 
types . 


Requirement:  F.  5 

Tyne  definitions  in  the  source  lanquaoe  will  permit  defini- 
tion of  both  the  class  of.. data  oniects  comprlsino  the  types 
and  the  set  of  operations  a-pjolicable  to  that  class.  A de- 
fined type  will  not  automat ical ly  inherit  the  operations  of 
the  data  with  which  it  is  represented. 


TACPOL  does  not  support  any  of  these  features. 


Requirement:  Eh 

The  data  objects  comprisinq  a defined  type  will  he  definable 
by  enumeration  of  thMr  literal  names,  as  Cartesian  products 
of  existinq  tynes  (i.e.,  as  array  and  record  classes),  by 
discriminated  union  (i.e.,  as  the  union  of  disloint  types) 
and  as  the  power  set  of  an  enumeration  type.  These  defini- 
tions will  oe  processed  entirely  at  como 1 le-t ime . 

TACPOL  does  not  suDPort  tne  capability  of  havina  user- 
defined  types.  Only  built-in  types  are  allowed. 


Requirement:  E7 

Tyne  definitions  Dy  free  union  (i.e.,  union  of  non-disjoint 
types)  and  suosettina  are  not  desired. 

T 
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Does  not  permit  free  unions  . . . . T 
Does  not  permit  subsettinq  .....  T 

TACDOL  meets  this  requirenent  since  no  method  of  type  oetin- 
ition  is  permitted. 


Requirement:  Ert 

When  defininq  a type,  the  user  will  be  able  to  specify  the 
init  ial  i zatior.  and  finalization  procedures  for  the  type  and  ,y' 
\ the  actions  to  oe  taken  at  the  time  of  allocation  ana  deal- 
location of  variables  of  that  tvpe. 

v --- 

TACPOL  does  not  suooort  user-defined  types. 
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SCHPFS  AND  LTRRAR1FS 
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•;  Requirement:  Fl 

Tne  lanquaqe  will  allow  the  user  to  distinoulsh  between 
scooe  of  allocation  and  scope  of  access. 

T AC POL  explicitly  addresses  scooe  of  allocation  rv  means  of 
a comprehensive  set  of  data  structures  which  can  he  de- 
clared. 

Scooe  of  access  is  not  addressed  explicitly,  alttouah  it  can 
be  derived  from  data  structure  des i qnat i or.s  in  the  prooram. 
Explicit  block  structures  with  local  scorinq  of  variables 
are  supported. 

The  cell  structure  in  TACPOL  permits  several  different  sub- 
structures to  be  allocated  the  same  physical  storaqe. 


I 
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Requirement:  K 2 

The  ability  to  limit  the  access  to  separately  defined  struc- 
tures will  be  available  both  where  tne  structure  is  defined 
and  where  it  is  used.  It  will  be  possible  to  associate  new 
local  names  with  separately  defined  orooram  components. 

TACPOL  does  not  support  user-defined  data  types,  nor  does  it 
distinguish  between  normal  and  "special"  structures. 

TACPOL  does  suooort  block  structures,  with  local  scobinq  of 
var iables. 


Requirement:  F 1 

The  scooe  of  identifiers  will  be  wholly  determined  at 
compi le-time. 


T 


TACPOL  meets  this  requirement. 


Requirement:  E4 

A variety  of  aool icat ion-or iented  data  and  operations  will 
be  available  in  libraries  and  easily  accessible  in  the 
1 amuaqe . 


P 


r 


'Variety  of  data  and  operations 
Fasilv  accessiole 


P 

P 


TACPOL  supports  tne  oroaran  use  of  COMPOOL  data  (although 
toe  FORMAL  DEF I M I T I ON  does  not  clearly  state  ho»  ) . Jr  addi- 
tion, a variety  of  intrinsic  procedures  are  available, 
although  tnis  set  is  predefined  and  not  alterable  r-y  tne 
user . 


By  means  of  the  CALL  statement,  separately  created  external 
procedures  can  oe  accessed.  Potentially,  tnis  feature  could 
be  used  to  access  user  libraries.  This  feature  is  not 
described  in  any  detail  in  the  FORMAL  DEFINITION. 


Requirement:  FS 
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Program  components  not  defined  within  the  current  program 
and  not  in  tne  oase  lanouaqe  will  be  maintained  in  compile- 
time accessible  libraries.  Tne  libraries  will  be  capable  of 
holding  anything  definable  in  the  language  and  will  not  ex- 
clude routines  whose  bodies  are  written  in  other  source 
languages . 

P 

Accessible  at  comoile-time  T 

Other  source  language  routines  . . . P 

Although  the  FORMAL  DEFINITION  does  not  describe  exactly 
how,  TACPOL  can  support  separate  program  components  which 
are  CALLed  as  needed.  It  these  components  have  beep  com- 
piled by  a TACPOL  compiler  using  the  CODE  language  feature, 
then  they  may  be  written  in  other  source  languages. 

TACPOL  does  not,  however,  allow  direct  calling  of  external 
routines  written  in  another  source  language  without  the  CODE 
feature. 


Requirement:  Fb 

Libraries  and  compools  will  be  indistinguishable.  They  will 
be  capable  of  holding  anything  definable  in  the  language, 
and  it  will  be  possible  to  associate  them  with  any  level  ot 
programming  activity  from  systems  through  orolects  to  indi- 
vidual programs.  There  will  be  many  specialized  comrools  or 
lioraries  any  user  specified  subset  of  which  is  immediately 
accessible  from  a qiven  program. 

U 

Libraries  and  CQMPOOLS  indi st inguishab le  . . . U 
Hold  anything  definable  in  language  U 


Many  levels  of  access u 

Many  specialized  subsets  n 


Libraries  are  not  explicitly  addressed  in  the  FORMA!  DF.F1NI- 


wa 


IION,  although  tne  aollity  to  call  an  external  procedure  im- 
plies their  existence.  COMPODl.S  are  said  to  exist,  but  no 
further  definition  of  COMPOOL  or  of  lanauaqe  mechanisms  to 
address  them  is  divert.  Hence,  the  required  features  are  un- 
defined. 


Requirement:  F7 

The  source  lanquaqe  will  contain  standard  machine  indepen- 
dent interfaces  to  machine  dependent  capabilities,  includino 
peripheral  equipment  and  special  hardware. 


— - p 

TACPOL  provides  machine  independent  interface  with  peri- 
pheral equipment  by  means  of  its  tile  nrocessinq  features 
(READ /WRITE  level).  The  "device"  is  desionated  only  throuon 
some  undefined  external  correspondence  with  the  program  file 
names.  Some  extension  of  this  capability  could  provide  an 
interface  with  other  special  hardware. 


9 * * : 

G.  CONTROL  STRUCTURES 


Requ 1 recent : G 1 

The  language  v i 1 I provide  structured  control  mechanisms  for 
sequential,  conditional,  iterative,  and  recursive  control, 
it  will  also  orovide  control  structures  for  (pseudo)  paral- 
lel orocessini,  exception  nandiinq  and  asynchronous  inter- 
rupt handlim. 


Sequential  control  T 

Conditional  control  . . . . T 

Iteration  T 

Recursion  F 

Parallel  orocessina  . . . . P 

Exceotion  handlina  p 

asynchronous  interrupts  . . l) 


In  addition  to  norrrei  sequential  execution,  TACPOT.  supports 
the  followin'?  control  elements: 

DU  ("dllF)  - iterative 

GOTO  - alter  execution  sequence 

IF  . . . THEN  . . . FLSE  - conditional 

Recursion  is  undefined  in  TACPOL,  and  appears  to  be  impossi- 
ble since  procedure  oodles  are  physically  inserted  in-line 
(macro  fasnion)  during  compilation. 

Parallel  orocessinq  is  not  defined  except  for  the  ability  to 
do  concurrent  l/n. 

Exceotion  nandiinq  is  defined  only  tor  three  cases  of  I/O 
processinq  - eod-of-file,  oad  record  Key,  bad  partition  key. 
In  addition,  condition  checking  can  oe  performed  on  divirie- 
by-zero,  fixed  overflow,  and  variable  usaqe. 

Interrupts  are  not  defined  explicitly  in  TACPPL.  The  wait 
operation  causes  orocessinq  to  be  suspended  until  all  I/O 
operations  on  a file  have  ceased. 


Requirement : G 7 

The  source  lanquane  will  provide  a "GOTO"  operation  applica- 
ble to  program  labels  within  its  most  local  scope  of  oefini- 
t i on . 


TACPOL  meets  this  requirement. 


Requirement 


« 


T 
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T ne  conditional  control  structures  will  be  fullv  partitioned 
and  will  permit  selection  atoni  alternative  computat  i ons 
based  on  the  value  of  a Boolean  expression,  on  the  subtvpe 
of  a value  from  a discriminated  union,  or  on  a computed 
choice  amono  laoeled  a 1 1 e r na t i ves . 


Fullv  partitioned  F 

Based  on  Boolean  expression  T 

Based  on  type  from  discr iminatod  union  . . F 

Based  on  computed  choice T 


The  ELSF  clause  in  the  IF  statement  is  optional. 

The  conditional  expression  in  an  IF  statement  must  be  a 
Boolean  expression.  The  selection  aroument  in  the  SaITCH 
intrinsic  procedure  (analooous  to  a CASK  statement)  must,  be 
a short  numeric  aroument. 

Discriminated  unions  are  not  defined  in  TACRO[  . 


Requirement:  G 1 

Tne  iterative  control  structure  will  oermit  the  termination 
condition  to  aooear  anywhere  in  the  Iood,  will  reouire  con- 
trol variables  to  be  local  to  the  iterative  control,  will 
allow  entry  only  at  the  head  of  tno  loor,  and  will  not  im- 
pose excessive  overhead  in  clarity,  or  run  the  execution 
costs  for  common  special  case  termination  conditions  (e.q., 
fixed  number  of  iterations  or  elements  ot  an  array  exhaust- 
ed). 


Termination  anywhere  in  loop  F 

Local  control  variables  U 

Entry  at  Iood  head  only T 

Efficient  and  clear  simple  cases  T 


Control  value  available  at  termination  . . U 

Execution  termination  of  a DO,  either  as  a result  of  control 
variable  value  or  of  WHILE  state,  takes  place  at  the  top  of 
the  looo,  since  these  conditions  are  only  evaluated  at  that 
time. 

Control  variable  must  be  a short  numeric  value, ♦ but  is  oth- 
erwise undefined  in  the  FORMAL  DEFINITION  as  helnq  local  or 
global.  Whether  the  end  value  of  the  control  variable  is 
available  is  not  defined  in  the  FORMAL  DEFINITION. 


Requirement:  G5 

Recursive  as  well  as  nonrecursive  routines  will  be  available 
in  the  source  lanauaqe.  It  will  not  ne  possible  to  define 
procedures  witnin  the  body  ot  a recursive  procedure. 


Recursive  and  nonrecursive  routines  P 

Explicitly  soecify  recursive  routines  F 

No  nested  recursive  procedures  T 

Recursive  procedures  are  not  defined  in  TACPO! • , and  appear 
to  ne  impossible  since  procedure  bodies  are  physically  in- 
serted in-line  (macro  fashion)  during  corno i 1 at  ion . 


Requirement:  Gb 

The  source  language  will  provide  a parallel  processing  capa- 
bility. This  capability  should  include  the  ability  to 
create  and  terminate  (possible  pseudo)  parallel  processes 
and  for  these  Processes  to  gain  exclusive  use  of  resources 
during  specified  portions  of  their  execution. 

T A c P 0 L does  not  support  parallel  processing. 


Requirement:  G7 

The  exception  handling  control  structure  will  permit  the 
user  to  cause  transfer  of  control  and  data  for  any  error  or 
exception  situation  wnicn  might  occur  in  a program. 

T AC  POL  supports  exception  handling  only  for  three  specific 
1/0  cases  --  end-of-file,  had  record  key,  bad  partition  key. 
In  addition,  the  following  program  conditions  can  ne  de- 
clared and  (presumably)  checked  --  divide  by  zero,  fixed 
overflow,  variable  usage.  Exactly  how  these  later  condi- 
tions are  processed,  once  detected,  is  not  defined. 


Requirement:  G3 

There  will  oe  source  language  features  which  permit  delay  on 
any  control  oath  until  some  specified  time  or  situation  has 
occurred,  which  permit  specif icat ion  of  the  relative  priori- 
ties among  parallel  control  paths,  which  give  access  to  real 
time  clocks,  and  which  permit  asynchronous  hardware  inter- 
rupts to  oe  treated  as  any  other  exception  situation. 


These  features  are  not  supported  by  TACPOL. 


H 


SYNTAX  AND  COMMKNT  COMVFMIONS 


Requirement:  HI 

The  source  language  will  be  free  format  with  an  explicit 
statement  separator,  will  allow  the  use  of  mnerron i ca  1 1 y sia- 
nificant  identifiers,  will  be  based  on  conventional  forms, 
will  have  a simple,  uniform  and  easily  parsed  aramnrar,  will 
not  provide  unique  notations  for  special  cases,  will  not 
permit  abbreviation  of  identifiers  or  key  words,  and  will  be 
syntactically  unambiguous. 


Free  format  witn  statement  separator  P 

rtnemonically  siqnificant  identifiers T 

Conventional  forms  P 

Simole  uniform  grammar  P 

Mo  special  case  notations  P 

No  abbreviation  of  keywords  or  identifiers  . . . T 
Unambiguous  grammar  T 


TAG POL  is  basically  of  tree  format  with  an  explicit  separa- 
tor (semicolon) . 

There  are  a tew  exceptions  to  this,  however,  including: 

- The  last  statement  in  a CUPK  block  must  have 
FNDsoace  in  columns  10-13 

- Within  certain  control  structures  (e.q.,  DO , It)  t.he 
semicolon  is  not  present  in  all  cases. 

It  allows  mnemonically  significant  identifiers,  and  utilizes 
generally  conventional  forms,  except  tor  some  designations 
of  complex  data  structures.  At  the  top  level,  the  grammar 
is  uniform,  put  data  structure  designations  can  be  far  from 
simple  or  uniform. 

Apbreviat ions  of  keywords  are  not  permitted.  The  grammar 
seems  to  be  unamoiguous. 


Requirement:  H2 

The  user  will  not  be  able  to  modify  the  source  lanauaoe  syn- 
tax. Specifically,  he  win  not  oe  able  to  modify  operator 
hierarchies,  introduce  new  precedence  rules,  define  new  key 
word  forms,  or  define  new  infix  operator  precedence. 

T 


T AC POL  meets  these  r egu i r ement s . 


Peguirement:  H3 


▼ 


*The  syntax  of  source  language  proqrams  will  be  c opposable 
from  a character  set  suitable  tor  publication  purposes,  but 
no  feature  of  the  language  will  be  inaccessible  using  the  e>4 
character  ASCII  subset. 


T AC  POL  uses  a SO  character  sunset  or  the  64  character  ASCII 
set . 


Requirement:  H4 

The  language  definition  will  provide  the  formation  rules  for 
identifiers  and  literals.  These  will  include  literals  for 
numbers  and  character  strings  ano  a breax  character  for  use 
internal  to  identifiers  and  literals. 

Literals  for  numbers  .....  T 


Character  strings  T 

Break  character T 


T AC  POL  meets  these  requirements.  The  break  character  is  the 
underscore . 


Requirement:  H5 

There  will  be  no  continuation  of  lexical  units  across  lines, 
but  there  will  be  a way  to  include  object  cnaracters  such  as 
end-of-line  in  literal  strings. 


Neither  of  these  r equ i rement s is  defined  in  the  TACPOL  FOR- 
MAL DEFINITION. 


Requirement:  H6 

Key  words  will  oe  reserved,  will  be  very  tew  in  number,  will 
oe  Informative,  and  will  not  be  usable  in  contexts  where  an 
Identifier  can  oe  used. 


TACPOL  recognizes  97  key  words,  all  of  which  are  fairly  in- 
formative in  context. 


Requirement:  H7 

The  source  lanquaqe  will  nave  a single  uniform  comment  con- 
vention. Comments  will  be  easily  distinguishable  from  code, 


will  be  introduced  oy  a sinale  (or  nossibly  two)  lanauaoe 
defined  characters,  will  permit  any  combination  of  charac- 
ters to  appear , will  oe  aole  to  appear  anywhere  reasonable 
in  programs,  will  automat ica l ly  terminate  at  end-of-)ine  if 
not  otherwise  terminated,  and  will  not  prohibit  automatic 
reformatting  of  programs. 


Single  comment  convention  T 

Distinguishable  from  code T 

Introduced  by  one  or  two  characters  . . . . T 

Contain  any  character  P 

Appear  anywhere  reasonable  P 

Terminate  at  end  of  line F 

Not  prohibit  reformattino  T 


TACPOL  comments  begin  with  /*  and  end  with  */. 
contain  any  TACPOL  character  excebt  / and  *. 


They  may 


In  TACPOL,  comments  may  appear  anvwnere  an  arbitrary  space 
may  appear.  Generally  this  is  reasonable,  although  over- 
zealous  use  of  comments  in  certain  contexts  (e.o.,  between 
the  Keyword  IF  and  the  conditional  expression  which  follows 
it)  may  maKe  the  oroaram  less,  rather  than  more,  readable. 

There  is  no  requirement  in  TACPOL  tnat  comments  terminate  at 
the  end  of  a line.  Only  */  can  terminate  a comment. 


Requirement: 


The  lanauaqe  will  not  permit  unmatched  parentheses  of  any 
Kind. 


TACPOL  meets  t.his  reouirement. 


Requirement:  H9 

There  will  oe  a jniform  referent  notation. 

In  general,  T.'PQL  uses  the  same  notation  tor  both  function 
calls  and  id>.*tifier  designations,  i.e,  the  name  of  the 
function  or  t i<  identifier  followed  by  arguments  in 
parentheses.  -*owever,  the  syntax  of  what  appears  in 
parentheses  is  highly  dependent  on  the  item  (function  or 
variable)  being  djscribed. 


Requirement:  HiO 

No  language  defined  *ymbols  appearing  in  the  same  context 


Will  have  pssent  ial  1 »'  different  meanings. 

_ - - p ... 

Generally,  TACPOL  meg;s  this  requirement  except  for  one 
case:  the  symbol  = used  tor  both  assignment  and  eauali- 

ty. 


1.  DEFAULTS,  CONDITIONAL  COMPILATION,  AND  LANGUAGE  RESTRICTIONS 


Requirement:  II 

There  will  be  no  default*  in  proarams  which  affect  the  pro- 
aram  ionic.  That  is,  decisions  which  affect  proqram  loqic 
will  oe  made  either  irrevocably  when  the  lanouaoe  is  defined 
or  explicitly  in  each  profam. 

Generally,  TACPOL  meets  thi  * requirement.  Certain  defaults 
are  allowed  however.  See  answer  to  Requirement  F3  for  some 
examples. 


Requirement:  i? 

Defaults  will  be  provided  for  special  capabilities  affectinq 
only  object,  r eor esentat ion  and  other  properties  which  the 
proqrammer  does  not  know  or  ci»e  about.  Such  defaults  will 
always  mean  that  the  pr on rammer  does  not  care  which  choice 
is  made.  The  Droorammer  will  t e able  to  override  these  de- 
faults when  necessary. 
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Generally,  TACPOL  fleets  tnis  re  fuirernent . See  II  and  fci  for 
exceot ions  • 


A 


The  source  lanquaqe  will  permit  tne  use  of  conditional 
statements  (e.q.,  case  statements)  dependent  cn  tne  object 
environment  and  other  compiie-time  var'ables.  in  such  cases 
tne  condition  will  be  evaluVed  at  comD'le-time  and  only  the 
selected  oath  will  oe  compiled. 


Although  T AC  POL  does  have  a S * ITCH  capability,  it  is  not 
used  in  the  manner  described. 


Requirement:  is 

The  source  lanquaqe  will  contai « a simple,  clearly  identifi- 
able base  or  Kernel  which  ^uses  all  the  power  of  the 
language.  To  the  extent  possible,  the  base  will  be  minimal 
with  each  feature  Drovidinq  a .inqle  unique  capability  not 
otherwise  duplicated  in  the  base.  The  choice  of  the  base 
will  not  detract  from  the  efficiency,  safety,  or  understan- 
dability  of  the  lanquaqe. 


TACPOi,  contains  no  such  base  or  Kernel. 




Requirement:  16 

Lamuaqe  restrictions  which  are  dependent  only  on  the  trans- 
lator and  not  on  the  object  machine  will  be  specified  expli- 
citly  in  the  lanquaqe  definition. 


f- 
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The  FORMAL  DEFINITION  of  TACPOL  explicitly  denotes  most  of 
these  restrictions,  including  the  number  of  array  dimensions 
and  lenoth  of  identifiers.  Other  translator  restrictions 
(e.q.,  depth  of  nested  parenthesis  levels  in  expressions  and 
maximum  number  of  identifiers  in  a program)  are  not  given  in 
the  FORMAL  DEFINITION  and  cannot  be  exblicitly  defined  P the 
user . 


« 


Requirement:  17 

Language  restrictions  which  are  inherently  dependent  only  on 
tne  object  environment  will  not  be  built  into  the  lanauaae 
definition  or  any  translator. 


1 
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*?ACPOL  meets  these  requirements. 


J.  EFF IC  1 FN  1 OBJECT  REPRESENTATIONS  AND  MACHINE  DEPENDENCIES 


Hequirement:  Jl 

Tne  language  and  its  translators  will  not  impose  run-time 
costs  for  unheeded  or  unused  generality.  They  <ill  he  caoa- 
hle  of  producing  efficient  code  for  all  programs. 

Run-time  considerations  (including  object  code  efficiency) 
are  not  defined  in  tne  TACPOL  FORMAL  DEFINITION. 


Requirement:  J2 

Any  optimizations  performed  by  the  translator  will  not 
change  the  effect  of  tne  program. 

These  considerations  are  undefined  in  the  FORMAL,  DIFINITION. 


Requirement:  J3 


Tne  source  language  will  provide  encapsulated  access  to 
machine  dependent  hardware  facilities  including  machine 
language  code  insertions. 


mm:  W.'  1 


1 AC  POL.  meets  most  of  this  requirement  with  its  C flit'  state- 
ment (which  orecedes  a olocx  ot  non-TACPOL.  statements). 

T AC  POL  does  not,  however,  support  comoi  le-t ime  conditional 
statements  of  the  sort  described  in  Peou  i r err.en  t II. 


Requirement:  .J4 

It  will  he  possible  within  the  source  language  to  specify 
the  object  presentation  of  composite  data  structures.  These 
descriptions  will  be  optional  and  encapsulated  and  will  be 
distinct  from  the  logical  description.  The  user  will  be 
able  to  specify  the  time/snace  trade-off  to  the  translator. 
If  not  specified,  the  object  representation  will  be  optimal 
as  determined  nv  the  translator. 


Specify  object  presentation  . . . . F 
Specify  time/space  tradeoff  . . . . T 

T AC PCi I,  meets  the  requirement  ot  time/space  tradeoff  with  its 
AL IGN/PACKKO  option  in  declarations . 

TACPOL  does  not  support  user  defined  object  presentation  of 
composite  data  structures. 


Requirement:  JS 

The  programmer  will  be  able  to  soecify  whether  calls  on  a 
routine  are  to  have  an  ooen  or  closed  imn 1 ementat  ion . An 
ooen  and  closed  routine  of  the  same  description  will  have 
identical  semantics. 


T AC  Pol,  expands  all  procedures  in-line,  and  does  not  expli- 
citly support  closed  procedures.  There  is,  however,  a 
suggestion  that  pre-compiled  external  procedures  can  oe 
called;  this  feature  is  not  explicitly  stated  or  described, 
however . 
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TACPnt,  (Evaluation  Summary 


This  section  presents  a summary  ot  the  findings  ot  the 
evaluation  of  the  TACPOL  language.  Strengths  and  weaknesses 
ot  the  language  are  Dresented.  Pequirements  for  language 
modification  necessary  to  meet  DOD  needs  and  functions  are 
addressed. 

TACPOL  has  a set  ot  strengths  which  conform  closely  to  the 
requirements  of  "TINMAN".  included  in  these  are  the  follow- 
ing: 
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well  defined  syntax  --  The  syntax  ot  the  TACpoi. 
language  cannot  be  altered  oy  the  user.  The  language 
is  based  on  a relatively  small  set  of  fairly  meaninoful 
keywords,  and  tnese  may  not  be  abbreviated.  The 
language  is  almost  completely  free  format. 

Strongly  tyoed  --  All  identifiers  used  in  a TACPOL  pro- 
gram must  be  declared  by  type  before  they  can  be  used. 
Type  checking  between  parameters  and  arguments  in  pro- 
cedures is  enforced. 

Block  structured  --  TACPOL  suDports  user  defined 
blocks,  within  which  local  scoping  of  identifiers  is 
nermitted. 

Declaration  and  designation  ot  variables,  literals,  and 
constants  --  TACPOL  meets  virtually  all  ot  these  re- 
quirements. 

TACPOL  also  suffers  from  numerous  significant  weaknesses, 
primarily  omission  of  certain  required  "TINMAN"  features. 
Tnese  include: 

Pointers  are  not  sunoorted. 

User  cannot  define  new  types  ot  operators  or  ennumera- 
tion  sets. 

Tnere  is  no  facility  for  uescrioinq  the  oblect  environ- 
ment or  providing  an  external  interface  to  the  run-time 
machine . 


Shortcomings  exist  in  the  definition  ot  iterative  and 
conditional  control  structures,  including  condition 
evaluation  and  a non-mandat  or  y E:LSh. 
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Becursion  is  not  well  defined. 

Parallel  nrocessing  is  not  supported,  nor  do  anv  time 


m 


dependent  features  exist. 


r 


Exception  handling  is  inadequate. 

The  symool  = is  used  as  an  assignment  as  well  as  a re- 
lational operator. 

There  is  a considerable  amount  of  defaulting  permitted, 


not  all  of  which  Is  consistently  applied. 

Tne  only  TACPOL  features  which  appear  to  exceed  " T 1 N M A N " 
specifications  are: 

The  intrinsic  procedure  hOOL  permits  evaluation  of  two 

nit  strings  according  to  a "truth  taole". 

The  numbers  and  sophistication  possible  tor  data  struc- 
tures are  cons i derab  le . 

Tne  syntax  of  TACPOL  does  appear  to  contort  to  the  rules 
specified  for  the  evaluation,  i.e.,  little  of  the  lanquaqe 
syntax  would  have  to  oe  modified  to  eliminate  clashes  with 
" T 1 iM M A N " requirements. 

TACPOL  utilizes  a fairly  common  set  of  constructs  (in  most 
cases).  The  language  itself  is  free  of  machine  dependent 
operations,  and  TACPOL  programs  could  potentially  be  moved 
to  a variety  of  machines.  There  are,  however,  a consider- 
aole  set  of  assumptions  aoout  the  compilation  and  target 
machines  which  may  make  such  transportability  difficult. 
(These  include  byte  and  word  sizes,  numeric  precision,  and 
an  ASCII  character  set  orientation.) 

/ 

Tne  conventions  used  for  declaration  and  designation  of  com- 
plex data  structures  (e.g.,  cells)  are  difficult,  not  always 
perfectly  consistent,  and  non-standard.  It  appears  to  be 
fairly  easy  to  make  a programming  mistake  in  this  regard. 

TACPOL  could  oe  modified  to  meet  most  of  the  "T1NVAU"  re- 
quirements, put  tnis  would  mean  adding  considerable  syntax. 
Most  such  modifications  would  be  st ra ioht f or  ward , such  as 
expanding  numeric  tyDes,  permitting  division  with  remainder, 
adding  "now",  supporting  address  pointers,  ana  changing  the 
symbol  used  for  relational  equality.  Others  could  be  made 
with  fairly  easy  language  modi f icat i ons , but  may  create 
serious  translator  ana  run-time  difficulties,  such,  as 
description  of  ooject  environment,  changing  the  iterative 
and  conditional  structure  syntax  rule  (includina  making  KLSK 
mandatory),  defining  recursive  procedure  calls,  adding  the 
syntax  to  support  parallel  processino,  ard  tightening  uc 
currently  oermitted  defaults.  finally,  there  are  some 
changes  which  may  require  considerable  new  syntax  and  may 
also  create  significant  translator  and  run-time  costs,  such 
as  oermittini  user  defined)  types,  operators,  and  power  sets 
of  ennumer at  ion  , expanding  ‘except i on  hanolina,  and  providing 
I/O  device  definitions.  \ 
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This  report  presents  an  evaluation  of  the  CMS-?  language 
wltn  the  requirements  listen  in  the  "TINmam"  (DOD  Re- 
quirements for  High  Order  Computer  Programming  Languages, 
"TINMAN"  - 1 March,  19  7 6,  Section  TV).  For  ourooses  of 

this  comparison  CMS-2  is  considered  to  be  defined  bv: 

USER'S  REFERENCE  MANUAL  (11)  FOP  COMP  IT  FD  MONITFP  SYS- 
TF v (CMS-2)  FOR  USE  WITH  AN/tJYK-7  COMPUTFP  --  M-5035 

CMS-2 Y NSFP'S  PFFERENCE  MANUAL  (PRELIMINARY  COPY)  — 
m-5049 

Throughout  this  report,  the  use  of  the  term  CMS-? 
denotes  CMS-2Y,  the  version  of  the  CMS-2  system, 
designed  for  use  with  the  AN/UYK-7  Computer. 

There  are  7R  language  requirements  listed  in  Section  4 of 
the  "TINMAN",  This  renort  compares  CMS-2Y  with  each  indi- 
vidual reguirement.  A summarv  of  tne  degree  to  which  the 
language  satisfies  each  requirement  is  presented. 

The  introductory  naragranh  of  each  "tinman"  reguirement 
included  as  the  leading  section  for  each  requirement 
eva 1 uat i on  . 

Symbols  blaced  beside  each  individual  reouirement  indi- 
cate the  degree  to  which  the  lanauaoe  meets  the  require- 
ment. The  symbols  and  their  meaning  are  as  follows: 

T - Totally  meets  requirement 

P - Partially  meets  requirement 

F - Poes  not  meet  requirement 

U - Unknown  from  available  documentation 


A.  DATA  AMD  TYPES 


Requirement:  A1 

The  lanquaqe  «111  be  typed.  The  type  (or  nr.ode)  of  all 
variables,  components  of  composite  data  structures,  ex- 
pressions, operations,  and  parameters  will  be  determin- 
able at  compile  time  and  unalterable  at  run  time.  The 
lanouaae  will  reauire  that  the  type  of  each  variable  and 
component  of  composite  data  structures  be  explicitly 
specifiel  in  the  source  nroaram. 

p 


In  General,  Cv.5-2  is  a typed  lanquaqe.  Most  types  are 
Known  at  compile  time.  However,  there  are  a few  instances 
where  tyoino  is  not  required  by  CMS-2.  These  are  as  fol- 
lows : 

Data  structures  can  be  defined  to  consist  of  machine- 
decendent  word  oroups.  In  thpse  cases,  it  is  strictly  up 
to  the  user  to  ne  coqnizant  of  any  data  manipulation 
problems  which  may  arise. 

Additionally,  the  OVERLAY  construct  provides  a method  for 
violation  of  type  chectina  mechanisms. 

In  CM.s-2  formal  parameters  need  not  be  explicitly  typed. 
CMS-2  assumes  a default  numeric  type  for  parameters. 

Implicit  variable  declarations  can  be  made  in  CMS-2. 
Aqain,  CvS-2  assumes  a default  intener  tvre  for  such  de- 
clarations. 


Type  checkinq  is  performed  at  compile  time.  however, 
numeric  data  units  are  considered  to  be  of  the  same  tvoe 
durino  assianment  and  evaluation  of  expressions;  Implicit 
conversions  take  Place  when  two  incomoatinle  numeric  un- 
its are  maniou lated.  This  fact  coupled  with  the  use  of 
the  OVERLAY  construct  provides  the  means  for  violation  of 
tvoe  rheckina  mechanisms.  In  this  sense,  CMS-2  does  not 
meet  the  full  Intent,  of  this  "TINMAN"  requirement. 


Requirement;  A? 

The  lanquaqe  will  provide  data  types  for  irteqer,  real 


(floating  ooint  and  fixed  point),  pool e an  and  character 
and  will  provide  arrays  (i.e.,  composite  o a t a structures 
with  indexable  components  of  homogeneous  type)  and 
records  (i.e.,  composite  data  structures  with  labeled 
components  of  het eroneneous  type)  as  type  Generators. 


1 nt  eqer T 

fixed  point T 

Floating  point T 

Character  string T 

Boolean T 

Arrays P 

Records P 


Arrays  and  Records  --  CMS-2  permits  both  arrays  (called 
TABLE'S)  and  Records  (also  called  TABLES).  CM5-2  does  not 
however,  provide  the  capability  of  using  arrays  and 
records  as  tyne  generators.  Thus  in  this  sense,  CMS-2 
does  not  meet  the  full  intent  of  the  "TINMAN". 


Requirement:  A3 

The  source  language  will  reouire  global  (to  a scope) 
specification  of  the  precision  for  floating  point  arith- 
metic and  will  permit  precision  specification  for  indivi- 
dual variables.  This  snec i f icat ion  will  be  interpreted  as 
tne  maximum  precision  required  by  the  program  looic  ana 
the  minimum  precision  to  be  supported  by  the  oblect  code. 

There  is  no  language  element  to  specify  the  precision  to 
be  used  in  floating  point  arithmetic  operations.  The  de- 
fault precision  used  in  all  floating  point  operations  is 
that  of  the  AN/UYF-7  computer. 

The  cost  of  implementing  floating  ooint  precision  specif- 
ication should  not  oe  too  great.  However,  programs 
currently  core  restricted  may  be  affected  adversely. 


Requirement:  A4 

Fixed  point  numbers  will  be  treated  as  exact  quantities 
which  have  a range  and  a fractional  step  size  which  are 
determined  by  the  user  at  compile  time.  Scale  factor 


management  wtlL  hp  donp  nv 
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comn  i i er 


CMS -2  totally  meets  this  requirement. 


Pegu i remenf : as 

Character  sets  will  be  treated  as  anv  other  enumeration 
tvne . 

CMS-?  has  a built  in  character  t ypp , which  represents  the 
ASCII  set  in  an  internal,  implementation  dependent,  col- 
lat i no  order. 

The  addition  of  EBCDIC  and  other  widely  used  character 
sets,  and  tne  run  time  conversion  packages  to  translate 
one  set  to  another,  could  be  done  at  modest  cost  to  the 
existing  implementations. 


Pegu i remen  t : Ae 

The  language  will  reauire  user  specification  of  the 
number  of  dimensions,  the  range  of  subscript  values  for 
each  dimension,  and  the  type  of  eacn  array  component. 
The  number  of  dimensions,  the  type  and  the  lower  sub- 
script bound  will  be  determinanle  at  compile  time.  The 
uoner  subscript  bound  will  be  determinable  at  entry  to 
the  array  allocation  scone. 


dumber  of  dimensions  fixed  at  compile  tine T 

Type  fixed  at  compile  time P 

Lower  suoscriot  pound  fixed  at  compile  tJme....T 

Subscripts  from  continuous  range T 

Subscripts  from  enumeration  type P 

Doper  subscript  bound  fixed  at  scope  entrv T 


Since  CWS-2  allows  untvoed  word  groups  to  be  components 
of  arrays,  the  language  partiallV  fails  the  reouirement 
that  the  tyoe  of  each  array  component  be  explicitly 
specified  bv  the  user. 

Subscripts  can  onlv  pe  integers  in  CMS- 2 . Since  character 
sets  are  not  an  enumeration  type  (see  AS  above)  in  CMS-2, 
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t he  lamuaqe  partially  fails  the  reanirp'nfnt  that  sub- 
scripts can  be  from  an  enumerated  type. 


Requirement:  47 

The  lanouaqe  will-  permit.  records  to  have  alternative 
structures,  each  of  whicn  is  fixed  at  compile  time.  The 
name  and  tvne  of  each  record  comoonent  will  te  specified 
dv  the  user  at  compile  time. 

vhile  records  (TARLKs)  can  have  alternative  structures  in 
C MS-2 , there  is  no  explicit  requirement  that  all  com- 
ponents of  records  be  named,  nor  tnat  they  be  typed. 
CMS-?  allows  array  components  to  he  a qrouo  of  continuous 
machine  words. 
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spin i renent : R 1 

Assignment  and  reference  ooeration  will  be  automatically 
defined  for  all  data  types  which  do  not  manage  their  data 
storaqe.  The  assignment  operation  will  permit  anv  value 
of  a given  type  to  be  assioned  to  a variable,  array  or 
record  component  of  that  type  or  of  a union  type  contain- 
ing that  type.  Reference  will  retrieve  the  last  assigned 
val ue . 


Variable  declaration  for  all  data  types T 

Encapsulated  type  declaration F 

Arrav  or  record  declaration T 


Encapsulated  tyoe  definitons  are  not  a part  of  Cn*S-2.  All 
items  in  an  array  or  table  can  be  assigned  using  one 
statement  in  C M S • 2 • 


Requirement:  R2 

The  source  language  will  have  a built-in  ooeration  which 
can  be  used  to  compare  any  two  data  oblects  (regardless 
of  type)  for  identity. 


Arrays  cannot  be  compared  in  their  entirety  in  CMs-2 . 
Cms-2  assumes  some  tvoe  conversions  when  two  distinctly 
typed  oblects  are  compared;  for  example,  when  a fixed- 
ooint  data  object  is  compared  to  a floatino  point  object, 
the  comoarison  would  be  done  algebraical ly  in  floating 
point . 


Requirement:  R3 

Relational  operations  will  be  aut omat i ca 1 l y defineo  for 
numeric  data  and  all  tyres  defined  oy  enumeration. 

P 

All  six  relational  operators  are  included,  tinordered  sets 
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are  not  included  in  CMS-2 


Requirement:  a 4 

The  nuilt-in  arithmetic  operations  will  include:  adoi- 

t i on , suotract ion,  multiplication,  division  (with  a real 
result.),  exponent  i at  i on , integer  divisior  (with  inteoer 
or  fixed  point  arquments  and  remainder),  and  neqation. 

T 


r^s-?  meets  this  requirement. 


Requirement:  ns 

Arithmetic  and  assianment  operations  on  data  which  are 
within  the  ranqe  specifications  of  the  proqram  will  never 
truncate  the  most  sionificant  digits  of  a numeric  quanti- 
ty. Truncation  and  rounding  will  always  be  on  the  least 
significant  digits  and  will  never  oe  implicit  tor  in- 
tegers and  fixed  point  numbers.  Implicit  rounding  beyond 
the  specified  precision  will  be  allowed  for  floatina 
point  numbers. 

p 

There  are  no  explicit  range  specifications  within  the 
CMS-2  language.  The  ranoes  are  implicit  in  that  the 
various  tvoes  represent  the  data  internally  in  lb, 32  or 
64  bit  form. 

There  is  only  one  precision  for  floating  noirt  numbers, 
and  C'S-2  uses  the  AN/UYK-7  rounding  instructions,  when 
tne  rounding  ontion  is  invoked. 


Pegu i rement : Rb 


The  built-in  boolean  operators  will  include  "AnP",  "np", 
"NOT",  and  "OP".  The  operations  "AND"  and  "OP"  will  re 
evaluated  in  short  circuit  mode. 


Short  circuit  "AND" ..r 

Snort  circuit  "OP" T 

NOT I 


T operation  "MR"  is  not  included  within  the  ldnauaae. 
Short  circuit  node  evaluation  for  scalars  is  defined 
within  the  lanauaqe. 


Requirement:  B7 

Thp  source  lanouaoe  will  permit  scalar  operations  and  as- 
signment on  conformable  arrays  and  will  permit  data 
transfers  between  records  or  arrays  of  identical  loaical 
structure. 


Assionment  between  records  and  arrays T 

Scalar  operations  on  arrays.. P 


Data  transfer  between  arrays  and  records  are  permitted  in 
CMS-?.  CMS- 7 makes  no  distinction  between  records  and 
arrays . 


Scalar  ooerations  are  permitted  only  on  variables,  and  on 
individual  elements  of  arrays  and  records. 


Menu i r emen  t : HR 

There  will  be  no  implicit  tvoe  conversions  but.  no  conver- 
sion operation  will  oe  required  when  the  tyne  of  an  actu- 
al parameter  is  a constituent  of  a union  type  which  is 
the  formal  parameter.  The  lanauaae  will  provide  explicit, 
conversion  ooerations  amonq  inteoer,  fixed  point  and 
floatim  ooint  data,  between  the  obiect  representation  of 
numbers  and  tneir  representations  as  characters,  and 
between  fixed  point  scale  factors. 


ExDlicit  conversions F 

No  imolicit  conversions F 

Explicit  oe tween  scale  factors T 


Implicit  tvoe  conversions  are  used  within  the  Cms-2 
lanouaoe  when  certain  options  are  invoked:  for  example, 
in  relational  expressions,  when  an  inteoer  and  a real 
number  are  compared,  the  inteoer  would  be  converted  to 
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the  real  format. 

Explicit  conversions  are  not  permitted  In  CMS-?.  Since 
all  numeric  data  units  are  considered  to  bp  of  the  same 
type*  internal  conversions  take  the  place  of  explicit 
conversions. 

The  format  capability  on  output  allows  oblect  representa- 
tions of  numbers  to  oe  decoded  as  characters. 


Requirement:  RR 

Explicit  conversion  operations  will  not  be  reouired 
Between  numerical  ranqes.  There  will  be  a run  time  excep- 
tion condition  when  any  integer  or  fixed  point  value  is 
truncated . 

---F 

The  capability  for  run  time  exception  checking  can  be  in- 
cluded within  the  language. 


I 


37 


Requirement:  iM  0 

The  base  language  will  provide  operations  allowing  pro- 
grams to  interact  with  files#  channels  or  devices  includ- 
ing terminals.  These  operations  will  permit  sending  and 
receiving  both  data  and  control  information#  will  enable 
programs  t.  o dynami  callv  assign  and  reassian  I/O  devices, 
will  provide  user  control  for  exception  conditions,  and 
will  not  oe  installation  dependent. 

CMS -2  is  oriented  toward  a serial  batch  processing  en- 
vironment. Its  inout/output  statements  are  insufficient 
to  handle  real  time  applications. 

No  capability  exists  in  CMS-?  for  dynamic 

assionment/reasstanment  of  I/O  devices. 

The  addition  of  powerful  I/O  capabilities  to  CMS-?  would 
oe  a ma  lor  effort. 


Regui rement : rtl i 
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The  lancjuaoe  *111  ornvHe  operations  on  data  types  de- 
fined as  power  sets  of  enumeration  types  (see  F6).  These 
operations  will  include  union,  intersection,  difference, 
complement,  and  an  element  predicate. 

---F--- 

Power  sets  are  not  defined  in  the  lanauaoe.  This  capabil- 
ity can  dp  added  without  much  difficulty. 


f.  EXPRESSIONS  AMO  PARAMETERS 


Requirement:  Ct 

Side  effects  which  are  dependent  on  tne  evaluation  order 
amono  tne  arquments  of  an  expression  will  ne  evaluated 
1 ef  t-to-r i qht . 

Arouments  of  an  expression  causinct  side  effects  are 
evaluated  lef t-to-r idht . 


Requirement:  C 7 

which  oarts  of  an  expression  constitute  the  operands  to 
each  operation,  within  that  expression,  should  be  obvious 
to  the  reader.  There  will  be  few  levels  of  operator 
hierarchy  and  thev  will  oe  widely  recoqnizeq. 

P 


Unambiouous  presentation P 

Pew  precedence  levels T 

Reouire  explicit  Darentneses F 

Mo  user  defined  levels... T 


CMS-2  has  six  precedence  levels.  There  are  some  cases 
where  the  use  of  the  unary  minus  operator  leads  to  ambi- 
quity.  For  example,  -3**2  evaluates  in  C^S-2  to  9;  but 
-A  * * 2 woere  A has  the  value  3,  evaluates  t.o  -9.  This 
evaluation  of  exponentiation  is  done  from  riaht-to-left 
in  the  latter  case,  and  is  ambiquons  at  best. 

Aqain,  tne  rules  for  evaluation  of  substitution  declara- 
tions are  quite  complex  and  confusinq. 


In  most  cases  however,  the  operands  to  each  operation  are 
easily  discernable. 


Requirement:  C3 

Expressions  of  a qiven  type  will  pe  permittee  anywhere  in 
source  oroqrams  where  both  constants  and  references  to 


variables  of  that  type  are  allowed 


T 

There  are  no  special  case  constraints  on  expressions  in- 
cluded in  the  syntax  of  the  lanquaae,  except  in  the  case 
of  substitution  declarations  where  the  torn  is  different. 


Requirement:  C4 

Constant  expressions  * i 1 1 be  allowed  in  Droqrams  where 
constants  are  allowed,  and  constant  expressions  will  be 
evaluated  before  run  tine. 

T 


This  requirement  is  fully  met  by  the  lanauaoe. 


Requirement.:  C5 

There  will  be  a consistent  set  of  rules  applicable  to  all 
parameter s , whether  they  be  for  procedures,  for  types  for 
exception  handlinq,  for  parallel  processes,  for  declara- 
tion, or  for  built-in  operators.  There  will  be  no  spe- 
cial operations  (e.o.,  array  structurino)  applicable  only 
to  parameters. 


Consistency  in  parameter  rules T 

Vo  special  parameter  operations P 

Cms- 2 has  a consistent  set  of  rules  for  all  parameters. 
However,  for  the  sake  of  efficiency,  the  lanauaae 
oesioners  have  included  a clause  allowinq  the  use  of  the 
machine  redisters  to  pass  parameters. 

This  lanjuaqe  clause,  "PARAMETER  DECLARATION"  associates 
one  of  the  user  specified  AN/HYK-7  machine  reuisters  with 
a formal  Parameter.  This  clause  is  hiohly  machine- 
deoendent  and  is  not  in  full  aareement  with  the  " T I M M A w " 
requirement  that  there  be  no  special  operations  applica- 
ble only,  to  parameters. 


Requirement:  Cf> 


Forma]  and  actual  parameters  will  always  anree  In  type . 
The  numoer  of  dimensions  for  array  Parameters  will  be 
det e rm. t nao  1 e at  compile  time.  The  size  and  subscript 
ranae  for  array  ' parameters  need  not  ne  determinable  at 
compile  time,  but  can  be  passed  as  oart  of  the  parameter. 

y 


dimensions  determined  at  compile  time T 

.Size  and  subscripts  can  pe  passed.. P 

Type  agreement  for  actual  and  formal  parameters P 


In  oenerai  there  is  agreement  of  tyoe  between  formal  and 
actual  oarameters.  However,  as  pointed  out  in  At,  all 
numeric  data  is  considered  to  d<>  of  the  same  type. 

There  is  no  direct  mechanism  tor  oassirn  of  size  and  sub- 
scripts of  arrays.  However,  throuoh  the  use  of  the  malor 
index  (size  indicator)  of  simple  tables  (one  dimensional 
arrays),  the  size  of  an  array  can  be  oasseo  as  a parame- 
ter. This  is  really  a restrictive  and  hidden  feature, 
and  practically  snea<ino,  the  lanouaoe  fails  the  intent 
of  the  " niMVJ"  reauirement. 


Heou i r ement : C7 

There  will  be  tour  classes  of  formal  parameters.  For 
data  there  will  be  those  which  act  as  constants 
representim  the  actual  parameter  value  at  time  of  call, 
and  those  which  rename  the  actual  parameter  which  must  be 
a variaole.  In  addition,  there  *ill  be  a formal  parame- 
ter class  tor  specifyina  the  control  action  when  excep- 
tion conditions  occur  and  a class  for  procedure  parame- 
ters. 


Parameter  constants P 

Parameter  variables P 

Exception  conditions T 

Procedure  Parameters F 


C^S-2  calls  are  made  by  value,  excppt  in  the  case  of  in- 
direct taples,  in  which  case  the  ChHAD  function  cell  mav 
oe  used  to  oass  tne  address  of  a load-ti^e  allocated 
table.  Actual  parameter  values  are  not  affected  bv  the 
call. 


Exception  conditions  can  be  stated  by  the  use  of  the  "FX 
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IT"  clause.  The  "EXIT"  clause  allots  tor  nroorarr.  control 
to  oe  transferred  to  one  of  the  named  statement  labels, 
which  have  to  be  within  the  scone  of  tne  cal  lino  pro- 
cedure block. 


Requirement:  CR 

SDeci f icat ion  of  the  type,  ranqe,  precision,  dimension, 
scale  and  format  of  parameters  will  be  optional  on  the 
formal  side.  'Jone  of  tnem  will  be  alterable  at  run  time. 


C^S-2  does  not  allow  for  deviation  from  the  specified 
lanauaqe  rules  for  writino  procedures. 


It  is  not  aopurent  to  tne  reviewer  now  this  requirement 
can  be  achieved  and  the  requirements  of  A1  and  A2  simul- 
taneously achieved.  Perhaps  a special  construct,  GENERIC, 
to  be  used  only  oy  an  elite  tiqhtly  controlled  aroup  of 
oroorammer s . 

Support  of  this  capability  requires  a sionificant  cnanoe 
to  the  tne  C S - 2 lanauaae. 


Requirement:  CR 

There  will  oe  provision  for  variaole  numbers  of  arou- 
ments,  but  in  such  cases  all  bjt  a constant  number  of 
them  must  be  of  the  same  tvre.  Whetner  a routine  can 
have  a number  of  arquments  must  be  determinable  from  its 
description  and  the  number  of  arquments  for  anv  call  will 
be  determinable  at  compile  time. 

p 


Variable  numoer  of  arquments P 

All  but  constant  number  same  type F 

Rumner  fixed  at  compile  time ......T 


The  numper  of  arquments  for  all  procedures  is  fixed  at 
compile  time.  CMS -2 
auired  parameters  on 
is  accomplished  by 
arquments  in  a call. 


does  allow  for  the  omission  of  unre- 
any  aiven  call  to  a procedure.  This 
the  use  of  commas  to  denote  missino 
However,  it  is  up  to  the  called  pro- 


cedur  e to  be  cognizant  of  the  fact  that  a few 
are  missim.  In  this  sense,  one  could  state 
allows  tor  a variable  number  of  arguments. 

The  reouirement  that  all  but  a constant  set  of 
able  number  of  arguments  be  of  the  same  type 
forced  in  Cms-2. 


parameters 
that  C»S-2 


the  vari- 
is  not  en- 


[>.  VARIABLES 


LITERALS  AND  CONSTANTS 


Requi  rement : 01 

The  user  will  have  the  anility  to  associate  constant 
values  ot  any  tyne  with  identifiers. 


The  lanquaqe  orovides  this  capability. 


Requirement:  D2 

The  lanauaqe  will  provide  a syntax  and  a consistent  in- 
terpretation for  literals  of  built-in  data  tvpes.  Numer- 
ic literals  will  have  the  same  value  (within  trie  speci- 
fied precision)  in  both  Droqr ams  and  data  (innut  or  out- 
put ) . 


Literals  of  d uilt-in  data  types 1 

Consistency  in  value li 


The  existinq  documentation  is  unclear  as  to  the  con- 
sistency of  values  in  both  programs  and  data. 


Requirement:  03 

The  lanouaqe  will  permit  the  user  to  specify  the  initial 
values  of  individual  variables  as  part  of  their  declara- 
tion. Such  variables  will  be  initialized  at  the  time  of 
their  aooarent  allocation  (i.e.,  at  entry  to  allocation 
scope).  There  will  be  no  default  initial  values. 


Declare  initial  values R 

Allocation  scope  initialization T 

No  default  values T 


Variables  and  components  of  taoles  can  be  set  to  prede- 
fined values.  However,  whole  arrays  or  tables  cannot  be 
preset.  Local  variables  (local  indexes  in  CKS-2)  cannot 
be  preset  either. 


There  are  no  default  values  in  C'^S-? 


Regui rement : D4 

The  source  language  will  require  its  users  to  specify  in- 
dividually tne  range  of  all  numeric  variables  and  the 
step  size  tor  fixed  point  variables.  The  range  specifi- 
cations will  pe  interpreted  as  the  maxima)  ranae  which 
must  be  supported  oy  the  ofciect  code.  Panne  and  step 
size  specifications  will  not  be  interpreted  as  defininn 
new  tyoes. 

---P 


Numeric  variable  ranqe  specification  mandatory F 

Step  size  tor  fixed  point  numbers  must  be  specified T 

Ranae  and  steo  size  not  defining  a new  tyre T 


No  explicit  range  speci f icat ions  are  mandatory  in  CMS-2. 
However,  tne  absolute  maximum  value  a fixed  point  vari- 
able can  take  is  implied  by  the  number  of  bits  reguested 
in  the  definition.  The  minimum  values  cannot  he  speci- 
f led. 

The  range  tor  floating  point  numbers  are  not  specifiable 
and  default  to  the  range  allowed  by  the  AN/UYK-7  comput- 
er. 


Reguirement:  DS 

Tne  range  of  values  which  can  be  associated  with  a vari- 
able, array,  or  record  component  will  be  anv  built-in 
type,  any  defined  type  or  a contiguous  subseauence  of  any 
enumeration  type. 


Enumeration  types F 

Defined  Tyoes F 

built-in  Types 1 


Variables,  array  components  and  Record  components  can  as- 
sume values  of  the  built-in  data  tyoes. 

'Jo  user  defined  types  arp  allowed  in  CMS-2. 
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Requirement:  Ob 

The  language  a- i 1 1 provide  a pointer  mechanism  which  can 
oe  used  to  build  data  with  shared  and/or  recursive  sub- 
structure. The  pointer  property  will  only  affect  the  use 
of  variables  (including  array  and  record  components)  of 
some  data  types.  Pointer  variables  will  be  as  safe  in 
their  use  as  are  any  other  variables. 

The  only  oointer  mechanism  as  sucn,  available  in  OS-?  is 
the  COR  AO  function  call  which  returns  the  address  of  the 
reauested  variaole,  table  or  array  component.  This  could 
oe  used  for  reference  and  assignment  purposes.  The  COraIj 
function  is  intended  primarily  for  indirect  tables. 

Tne  addition  of  a powerful  pointer  capability  to  C h S - 2 
will  require  significant  modifications  to  the  present  i m - 
olementat ions . 


E.  DEFINITION  FACILITIES 


Requ i rement : El 

The  user  of  the  lanquaqe  will  be  able  to  define  new  data 
tyres  and  operations  within  his  proqrams. 

CMS-2  is  restricted  to  the  use  of  built-in  data  types. 
The  definition  of  new  types  and  operations  as  intended 
here  are  not  supported  by  the  lamuaqe. 


Requirement:  E2 

The  "use"  of  defined  types  will  he  indi s t i nqui snahle  from 
built-in  types. 

The  lanquaqe  does  not  permit  definition  of  new  data  types 
as  an  operation. 

This  capability  can  be  added  to  tne  lanouaae  as  an  exten- 
sion of  Ei . 


Requirement:  E3 

Each  proqram  component  will  be  defined  in  the  base 
lanquaqe,  in  a library,  or  in  the  orooram.  There  will  be 
no  default  dec larat ions  . 


Local  variaDles  can  be  declared  implicitly  in  CMS-2.  They 
default  to  a s ianed-i nteqer  type. 

Removal  of  such  implicit  declarations  should  be  trivial. 


Requirement:  E 4 

The  user  will  be  able,  within  the  source  lanouaqe,  to  ex- 
tend existinq  operators  to  new  data  types. 

---F 


jr-f*.  a - 
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The  lanouaqe  does  not  permit  new  type  definition.  This 
capability  can  be  included  as  part  of  the  extension  to 
type  definition. 


Requirement:  E 5 

Type  definitions  in  the  source  lanauaqe  will  permit  de- 
finition of  noth  the  class  of  data  objects  con-.orisina  the 
types  and  the  set  of  ooerations  applicable  to  that,  class. 
A defined  type  will  not  automat ical ly  inherit  the  opera- 
tions of  the  data  with  which  it  is  represented. 

The  lanquaqe  does  not  support  user  defined  types. 


Requirement:  E6 

The  data  objects  comorisinq  a defined  type  will  be  defin- 
able oy  enumeration  of  their  literal  names,  as  Cartesian 
products  of  existind  tvpes  Ci.e.,  as  array  and  record 
classes),  by  discriminated  union  (i.e.,  as  the  union  of 
disjoint  tyoesl  and  as  tne  power  set  of  an  enumeration 
tyoe.  These  definitions  will  be  processed  entirely  at 
comoi le  time. 

Enumerat  * on F 

Cartesia  , products T 

IHscriminf  ted  union F 

Power  set  of  enumeration  type....F 

Tne  TABLE  *echanism  is  used  to  define  records.  Its  use  is 
limited,  h.'wever.  Records  do  not  define  types  and  cannot 
pe  used  as  tyoe  constructors. 


Requirement:  E7 

Type  definitions  by  free  union  (i.e.,  union  of  non* 
disjoint  types)  and  suosettina  are  not  desired. 

Ooes  not  permit  free  unions F 

hoes  not  permit  subsettinq F 


*v£, v j i|  i I rn  > I 
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Free  unions  are  permitted  with  the  use  of  the  OVERLAY 
canahilities  in  Jms-2. 

Subsettinq  is  pjfsible  by  the  use  of  the  SUB-TABLE 
mechani sm. 


Requirement:  E8 

vJhen  defining  a tyv,  the  user  ♦'ill  be  able  to  specify 
the  in i t ial i zat ion  and  finalization  procedures  for  the 
type  and  the  actions  to  he  taken  at  the  tire  of  alloca- 
tion and  deallocatioi  of  variables  of  that  type. 

New  tvpes  cannot  be  divined  within  the  lancmaoe. 


F.  SCOPE1  > AND  LIBRARIES 


Requirement:  F’l 

Thp  language  will  allow  the  user  to  distinguish  Between 
scope  ot  allocation  and  sc  >pe  of  access. 

In  C^S-?,  the  scone  of  alloration  of  all  data  structures 
is  the  duration  of  the  program,  with  the  exception  of  lo- 
cal varianles  (local  indexes'  where  the  variable  is  ac- 
cessible for  the  duration  of  » he  defining  procedure. 

Tne  scone  of  access  for  all  data  structures  is,  aaain, 
throughout  the  program  for  dV a declared  in  system-data- 
desians  (?looal  definitions);  for  data  declared  in 
local- data-desions  the  scope  ot  access  is  limited  to 
those  nrouDs  ot  procedures;  for  ’ocal  indexes,  the  scope 
of  access  is  limited  to  the  oroiedure  definino  the  local 
index . 

The  modifications  reouired  to  alliw  a true  local/oiohal 
definition  facility  would  be  sipiticant,  since  tne  re- 
quired changes  would  have  to  allow  for  hoth  allocation 
and  deallocation  of  data  structure,. 


Reoui rement : F2 

The  ability  to  limit  the  access  to  separately  defined 
structures  will  be  available  both  where  the  structure  is 
defined  and  where  it  is  us*d.  It  will  be  possible  to  as- 
sociate new  local  names  with  separately  defined  program 
components . 

As  stated  above,  access  to  d ita  structures  is  limited  by 
the  physical  location  of  the  data  declarations.  The  only 
exception  to  this  rule  is  as  tollows; 

By  using  the  EXTDEK  and  FIXTRF.F  clauses  data  structures 
declared  locally  can  be  made  g, 'really  accessible. 

The  assessment  of  the  cost  and  impact  of  the  modifica- 
tions  necessary  to  incorporate  this  requirement  can  be 
made  in  conlunction  with  the  modifications  neccessary  for 
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implementim  requirement  FI. 


Requirement:  F 3 

The  scope  of  identifiers  will  be  wholly  determined  at 
compile  time. 

This  requirement  is  completely  met  py  the  lanquaoe. 


Requ i rement : F4 

4 variety  of  application-oriented  data  and  operations 
will  be  available  in  libraries  and  easily  accessible  in 
the  language. 

Applications  oriented  data  and  subroutines  can  be  stored 
in  common  libraries  which  are  easily  accessible  by  CMS-?. 


Requirement:  Fb 

Program  components  not  defined  within  the  current  program 
and  not  in  the  base  lanquaoe  will  be  maintained  in  com- 
pile time  accessible  libraries.  The  libraries  will  be 
capable  of  holding  anything  definable  in  the  languaae  and 
will  not  exclude  routines  whose  bodies  are  written  in 
other  source  languages. 

p 


Accessible  at  compile  time T 

Other  source  lanquaoe  routines P 


The  language  does  not  preclude  routines  written  in  a dif- 
ferent source  language.  As  long  as  the  routines  exist  in 
a source  form  compatible  with  the  CMS-?  library  manipula- 
tors they  can  reside  in  system  libraries.  There  is  no 
provision  for  interface  checking  in  the  language.  Hence, 
it  cannot  be  said  whether  foreign  lanquaoe  routines  can 
exist  in  object  form  in  the  system  libraries. 


Requirement.:  F6 


Libraries  and  compools  will  re  indist inquishan  le.  They 
will  re  canable  of  holdina  anythina  detina»le  in  the 
language,  and  it  will  op  possible  to  associate  them  with 
any  level  ot  programming  activity  from  systems  through 
Droiects  to  individual  nroqrams.  There  will  oe  rrany  spe- 
cialized comoools  or  libraries  any  user  specified  subset 
of  which  is  immedi  ate  ly  accessible  from  a aivej  program. 

p 


(libraries  and  comoools  indistinguishable ,....p 

Hold  anything  definable  in  language T 

Many  levels  ot  access T 

Many  specialized  sunsets T 


CMS- 2 libraries  and  comoools  can  hold  anvthirq  df finable 
in  the  language.  However,  tor  elements  being  selected 
from  a comoool,  the  user  has  to  state  that  a corr' ol  is 
oeing  selected. 


Requirement:  F7 

The  source  language  will  contain  standard  machine  in- 
deoendent  interfaces  to  machine  dependent  caoabil it  ies  , 
including  oerioneral  eguibment  and  special  hardware. 

Cms-2  has  a limited  high  level  I/O  capability.  A limited 
set  bf  peripheral  eauibment  and  special  hardware  is  sup- 
ported. See  comments  under  H10. 


G.  CONTRUL  STWIIC  TUf-h  S 


Requirement:  G1 

The  language  v i 1 1 provide  structured  control  mechanisms 
for  sequential,  conditional,  iterative,  and  recursive 
control.  It  will  also  provide  control  structures  tor 
(oseudo)  Darallel  processing,  exception  handling  ana 
asynchronous  interrupt  handling. 


Sequential  control T 

Conditional  control T 

Iteration T 

Recursion F 

Parallel  Drocessing F 

Exception  handling P 

Asynchronous  interrupts F 


The  language  orovides  the  following  keywords  for  control 
mechanisms : 

FOR 

GOTO 

IF  . . . . THEN  ....  ELSE. 

VARY 

Exception  handling  is  provided  py  use  of  the  abnormal 
exit  and  the  ability  to  alter  the  sequence  of  execution 
overflow  upon  condition  detection  of  parameters. 

The  language  does  not  provide  an  explicit  mechanism  for 
interrupt  handling. 

Similarly,  there  is  no  explicit  definition  of  parallel 
processing.  Addition  of  this  to  the  structure  of  the 
language  will  require  malor  language  modification. 

In  general,  tne  language  control  mechanisms  conform  to 
"TINMAN"  requirements.  The  addition  of  the  other  "TIN- 
MAN" capabilities  to  CMS-2  would  be  a non-trivial  effort. 


Requirement:  G2 

The  source  language  will  provide  a "GOTO"  operation  ap- 


Plicable  to  program  labels  within  its  most  local  scope  ot 
def  init  ion. 


C'^S-i  permits  the  GOTO  target  to  De  any  label  in  the 
system-Drocedure. 

Holes  governing  the  GOTO  operation  can  oe  mortified  to 
preclude  branches  out  of  scope. 


Hequirement:  G3 

Tne  conditional  control  structures  will  be  fully  parti- 
tioned and  win  permit  selection  amona  alternative  compu- 
tations based  on  the  value  of  a Boolean  expression,  on 
the  subtype  of  a value  from  a di scriminatert  union,  or  on 
a computed  choice  among  labeled  alternatives. 


Based  on  3oolean  expression.......... T 

Based  on  type  from  discriminated  union F 

Based  on  computed  choice T 


Conditional  control  based  on  Boolean  expressions  is  pro- 
vided for  by  the  IF-THEM-ELSE  construct.  Case  statements 
and  switches  Drovide  for  a computed  choice  among  labeled 
a 1 ter nat i ves  . 

The  language  does  not  require  that  all  alternatives  be 
accounted  for;  for  example,  an  "KLSK"  clause  is  not  man- 
datory for  all  " IF-THEN"  expressions. 

There  are  no  simple  mechanisms  tor  common  cases. 


Hequirement;  G4 

The  iterative  control  structure  will  permit  the  termina- 
tion condition  to  anpear  anywhere  in  the  loop,  will  re- 
quire control  variables  to  be  local  to  the  iterative  con- 
trol, will  allow  entry  only  at  the  head  of  the  loop,  and 
will  not  impose  excessive  overhead  in  clarity,  or  run  the 
execution  costs  for  common  special  case  termination  con- 
ditions ( e . g . , fixed  number  of  iterations  or  elements  of 
an  array  exhausted). 


Termination  anywhere  in  loop 

Local  control  variables 

Entry  at  loon  head  only 

Efficient  and  clear  simple  cases 

Control  value  available  at  termination 

Termination  witnin  a loop  is  made  possible  by  several 
constructs  within  the  lanquaqe.  Termination  can  be  at 
the  head  of  the  loop  (after  a fixed  number  of  iterations 
or  failure  of  a test  - WHILE),  at  tne  ena  of  the  loop 
(test  - UNTIL)  and  within  the  loop  (usina  the  GOTO). 

(iOOPs  can  be  entered  at  any  labeled  statement. 

The  control  variable  may  or  may  not  occur  within  the  con- 
trolled statement.  The  controlled  variable  is  a word 
reference,  i.e.,  either  an  anonymous  reference  or  a de- 
clared word  reference.  The  value  of  the  controlled  vari- 
able is  availanle  for  declared  word  references. 

Tne  rules  for  iterative  evaluation  can  be  redone  to  com- 
pletely meet  "TINMAN"  r eau i r ement s . 


Requirement:  G5 

Recursive  as  well  as  nonrecursive  routines  will  be  avail- 
able in  the  source  lanquaqe.  It  will  not  be  possible  to 
define  procedures  within  the  body  of  a recursive  pro- 
cedure. 


Recursive  and  nonrecursive  routines K 

Explicitly  soecify  recursive  routines F 

No  nested  recursive  procedures F 


Recursion  is  not  provided  in  Cms-2. 


Requirement:  Gf> 

The  source  lanquaqe  will  provide  a parallel  processinq 
capability.  This  capability  should  include  the  ability 
to  create  and  terminate  (possiole  pseudo)  parallel 
processes  and  for  these  processes  to  qain  exclusive  use 
of  resources  durinq  specified  portions  of  their  execu- 
t ion . 


The  language  does  not  explicitly  address  parallel  pro- 
cessina  reguirements. 


^eguirement:  G ? 

The  exceotion  handling  control  structure  till  permit  the 
user  to  cause  transfer  of  control  and  data  tor  any  error 
or  exceotion  situation  which  miqht  occur  in  a program. 

Cws-2  does  not  provide  a general  exception  handling  capa- 
bility. The  only  constructs  available  are  abnormal  exit 
oarameters  and  overflow  conditions. 

Addition  of  exception  control  constructs  to  the  language 
will  be  a nontrivial  process. 


^eauirement:  G s 

There  will  ne  source  language  features  which  perm.it  delay 
on  any  control  oath  until  some  specified  time  or  situa- 
tion has  occurred,  which  permit  specification  of  the  re- 
lative nriorities  among  parallel  control  paths,  which 
give  access  to  real  time  clocks,  and  which  permit  asyn- 
chronous hardware  interrupts  to  be  treated  as  any  other 
exceotion  situation. 

This  reouirement  aooears  to  expand  or,  the  G6  reouire- 
ments.  Parallel  processing  capabilities  can  ne  added  to 
the  language.  This  addition  will  oe  costlv  and  mav  tend 
to  cloud  the  readability  and  clarity  of  tne  language. 
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Requirement:  R1 

The  source  languaae  will  oe  free  format  with  an  explicit 
statement  separator,  will  allow  the  use  of  mnemonical  ly 
significant  identifiers,  will  be  based  on  conventional 
forms,  will  have  a simple,  uniform  and  easily  parsed 
grammar,  will  not  provide  unioue  notations  for  special 
cases,  will  not  permit  abbreviation  of  identifiers  or  key 
words,  and  will  oe  svntact ical ly  unambiguous. 


Free  format  with  statement  separator T 

Mnemonical  ly  sionificant  identifiers T 

Conventional  forms P 

Simple  uniform  arammar P 

Mo  special  case  notations P 

Mo  abbreviation  of  keywords  or  identifiers....! 
iinampiauous  grammar P 


C^S-2  is  a tree-format  language.  There  are  a number  of 
special  cases  used  in  the  grammar  ot  the  languaae,  for 
example,  tne  rule  for  Boolean  operations  is  ouite  com- 
plex. Tne  rules  for  substitution  expressions  are  dif- 
ferent from  normal  usage. 


The  syntax  of  source  language  programs  will  be  comoosacle 
from  a character  set  suitable  tor  publication  purposes, 
out.  no  feature  of  the  language  will  be  inaccessible  usino 


the  64  character  ASCII  subset 


The  lanciune  satisfies  this  requirement. 


Requirement:  H4 

Tne  lanquaqe  definition  will  provide  the  formation  rules 
for  identifiers  and  literals.  These  will  include 
literals  tor  numbers  and  character  strinos  and  a break 
character  for  use  internal  to  identifiers  and  literals. 


Literals  for  numbers.. T 

Character  strinos T 

break  character K 


Identifiers  can  bn  from  one  to  einnt  characters  in 
len7fh.  However,  the  first  character  has  to  be  an  alpha- 
bet ic  . 

There  are  no  oreax  characters,  per  se,  in  CMS-2.  As  a 
consequence,  tnere  are  elaborate  rules  as  to  where  a 
snace  can  r>e  used,  and  the  usaoe  is  context  dependent, 
break  Characters  could  be  introduced  into  the  lanquaqe 
with  minor  nojifications. 


Requirement:  MS 

There  will  be  no  continuation  of  lexical  units  across 
lines,  but  there  will  be  a way  to  include  oblect  charac- 
ters sucn  as  end-of-line  in  literal  strinqs. 

Multiple  lines  are  permitted  within  the  lanauaqe  struc- 
ture. It  should  be  very  simple  to  cnanqe  this  feature. 


Requi  r emen t : Hf> 

key  words  will  be  reserved,  will  be  very  few  in  number, 
will  be  informative,  ano  will  not  be  usable  in  contexts 
where  an  identifier  can  be  used. 

---p 


in 


The  lanouaoe  defines  17J  Key  words.  The  proliferation  of 
Key  words  is  hiihly  indicative  of  the  complexity  of  the 
i angua te . 


Requirement:  H7 

The  source  language  will  have  a single  uniform  comment 
convention.  Comments  will  be  easily  distinauishable  from 
code,  will  he  introduced  by  a sinqle  (or  possibly  two) 
language  defined  characters,  will  permit  any  combination 
of  characters  to  appear,  will  oe  able  to  appear  anywhere 
reasonaole  in  programs,  will  automat  tea) lv  terminate  at 
end-of-line  it  not  otherwise  terminated,  and  will  not 
DrohiDit  automatic  reformattina  of  programs. 


Simle  comment  convention F 

Distinguishable  from  code P 

Introduced  by  one  or  two  cnaracters P 

Contain  any  cnaracter T 

Appear  anywhere  reasonable T 

Terminate  at  end  of  line F 

Mot  prohibit  reformatting T 


Comments  may  oe  expressed  in  three  for ’ns: 
COMMENT  <st  r i nq> 


RracKet  Motes:  These  are  sDecialized  documentation 
features  associated  witn  system  declarations  and 
data  declarations. 


Strings  quoted  by  apostrophes:  These  can  appear 

anywnere  a soace  can  within  a statement. 


Tnese  three  forms  can  be  replaced  with  lust  one  of  these 
forms,  with  minor  effort. 


Reouirement:  HR 


The  language  will  not  permit  unmatched  parentheses  of  anv 
Kind. 
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T 

The  language  does  not  oer^it  unmatched  oarentheses. 


Reou i recent : H9 

There  will  oe  a uniform  referent  notation. 

All  notation  is  consistent,  exceot  tor  the  intrinsic 
functions,  BIT  and  CHAR. 


Requirement:  H10 

Mo  language  defined  symbols  appearing  in  the  same  context 
will  have  essentially  different  meanings. 


There  are  several  cases  where  tne  meaninq  of  lanquaqe 
symbols  is  context  deoendent . 


- and  and  OR  are  both  looical  connectors  and  bit- 
string  ooerators. 


- THEN  is  both  a statement  connector  and  a conditional 
statement  connector,  i.e.,  IF  ...  THEN. 


- EQU A i,s  has  three  meaninos  - numeric  constant  EOUAf.S, 
the  difference  in  addresses  between  allocated  iden- 
tifiers and  the  allocation  of  an  identifier. 


This  leads  to  considerable  ambiguity  in  usaoe.  Changes 
to  eliminate  this  confusion  would  require  changing  both 
the  syntax  as  well  as  the  translators. 


-3?- 


I.  DEFAULTS,  CONDITIONAL  COMPILATION,  AND  LANGUAGE  RESTRICTIONS 


Requirement:  II 

Tnerp  will  ne  no  defaults  in  croarams  which  affect  the 
oroaraTi  logic.  That  is,  decisions  which  effect  prooram 
looic  will  be  made  either  irrevocably  when  the  language 
is  defined  or  explicitly  in  each  proaraf. 


This  requirement  is  satisfied  by  the  language. 


Requi recent : 1 7 

Defaults  will  be  provided  for  special  capabilities  af- 
fect im  only  obiect  renresentation  and  other  properties 
which  the  nroarammer  does  not  know  or  care  about.  Such 
defaults  will  alwavs  mean  tnat  the  proarammer  does  not 
care  which  choice  is  made.  The  programmer  will  oe  able 
to  override  these  defaults  when  necessary. 

p 

In  general  the  language  does  not  permit  defaults.  Howev- 
er, there  are  some  exceptions.  For  example,  the  mode  of 
nacKinq  of  TA!3LE  fields  can  be  selected  by  the  programmer 
or  he  can  let  the  compiler  manaqe  it  optimally.  Reen- 
trant procedures  have  to  be  explicitly  specified  or  the 
mode  is  non-reentrant. 


Requirement:  13 

The  user  will  be  able  to  associate  compile  time  variables 
with  programs.  These  will  include  variables  which  speci- 
fy the  obiect  computer  model  and  other  aspects  of  the  ob- 
iect machine  configuration. 

CMS- 2 does  not  allow  this  capability.  The  onlv  available 
compile  time  feature  is  the  ability  to  selectively  com- 
pile nieces  of  source  code.  Addition  of  this  capability 
»ould  require  maior  modifications. 


Requirement:  14 
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Tne  source  language  * 1 1 ] nermit  cue  use  of  conditional 
statements  (e.o.,  case  statements)  dependent  on  the  ob- 
lect  environment  and  other  compile  rime  variables.  In 
such  cases  the  condition  will  ne  evaluated  at  compile 
time  and  only  the  selected  path  will  be  compiled. 

Selective  compilation  is  possible  usina  the  CSW1TCH 
mechanism.  This  allots  for  compilation  onlv  when  the 
CSwTTCH  "flag  variable"  is  set  on.  This  capability  does 
not  meet  the  full  intent  of  the  "TINMAN"  requirement. 
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Reou  i rement : lb 

Tne  source  language  will  contain  a simple,  clearly  iden- 
tifiable oase  or  kernel  which  houses  all  the  oower  of  the 
language.  To  tne  extent  possible,  the  base  will  be 
minimal  with  each  feature  providing  a sinole  unioue  capa- 
bility not  otherwise  duplicated  in  tne  base.  The  choice 
of  the  base  will  not  detract  from  the  efficiency,  safety, 
or  under standabi 1 ity  of  tne  language. 

As  far  as  can  be  determined,  the  base  or  kernel  consti- 
tutes the  entire  language. 


Reouirement:  16 

Language  restrictions  which  are  aeoendent  only  on  the 
translator  and  not  on  tne  obiect  machine  will  be  speci- 
fied explicitly  in  the  1 anauaoe  definition. 

p 

Available  documentation  describing  comniler  limits  is 
precise  in  some  areas  and  vaaue  in  others,  for  example, 
array  dimensions,  identifier  lengths,  and  nesting  limits 
are  explicitly  defined.  The  number  of  identifiers  allow- 
able is  not  explicitly  defined. 

Limits  are  probably  deoendent  upon  the  machine  environ- 
ment in  at  least  some  cases. 


J.  EFFICIENT  OBJECT  REPRESENTATIONS  A NO  MACHINE  DEPENDENCIES 


Requirement:  J 1 

Toe  language  and  its  translators  will  not  impose  run  time 
costs  tor  unneeded  or  unused  oeneralitv.  They  will  be  ca- 
pable of  oroducim  efficient  code  tor  all  oroarairs. 

mm  * f J • m • 


It  is  not  clear  from  the  documentation  as  to  how  the  code 
denerators  function.  Also,  the  evaluator  cannot,  deter- 
mine whether  run-time  support  routines  are  used. 


Reou i rernent : ,J? 

Anv  optimizations  performed  by  the  translator  will  not 
chanoe  the  effect  of  the  orooram. 

Insofar  as  it  is  known  to  the  evaluator,  optimization 
done  by  the  CMS-2  compiler  does  not  chanoe  the  effect  of 
the  proor am . 


Requirement:  J3 

Tne  source  lanouaqe  will  provide  encapsulated  access  to 
machine  dependent  hardware  facilities  includjna  machine 
lanouaoe  code  insertions. 


The  DIRFiCT  CODFJ  construct  provides  this  capability. 


Reouirement:  J4 

It  will  ne  possible  within  the  source  lanauaae  to  specify 
the  object  presentation  of  composite  data  structures. 
These  descriptions  will  be  optional  and  encapsulated  and 
will  be  distinct  from  the  looical  description.  Tne  user 
will  be  aole  to  specify  the  time/space  trade-off  to  the 
translator.  If  not  specified,  the  object  representation 
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will  be  optical  as  determined  bv  the  translator. 

---P--- 


SDecifV  object  presentation P 

Soecify  time/space  tradeoff P 


This  capability  is  somewhat  available  tnrouoh  use  of  the 
TABLt:  construct.  Field  orders,  field  widtis,  bit  pat- 
terns and  field  structures  can  all  be  specified  within  a 
table  structure. 

There  is  no  mechanism  for  explicitly  soecifyina 
tradeoffs.  However,  the  translators  do  in  eact  optimize 
data  manipulations  for  the  object  computer. 


Requirement:  J5 

The  oroorammer  will  he  able  to  specify  whether  calls  on  a 
routine  are  to  have  an  open  or  closed  i odI e^ent at i on . An 
ooen  and  closed  routine  of  the  same  description  will  have 
identical  semantics. 

All  user  defined  procedures  and  functions  are  closed. 
The  lanaoa'ie  could  be  modified  to  add  this  capability. 
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Cms-2  Evaluation  Summary 


This  section  presents  a summary  of  the  fjnrlinqs 
resulting  from  this  evaluation  ot  CMS-?.  Tne  strenqtns 
and  weaknesses  of  the  language  are  noted.  The  feasibili- 
ty of  molifying  the  language  to  fully  meet  the  "TINMAN" 
requirements  is  discussed. 


CMS-?  nas  the  following  strong  points  in  comparison 
with  tne  "Tinman". 


- Well  defined  Syntax  --  syntax  ot  the  language  cannot 
be  changed;  no  keyword  abbreviat ions ; language  is 
free  format. 


- Binding  Caoabilitv  --  program, s may  r,e  compiled 
separately  and  linked  at  execution  time;  COkpnOLS 
can  be  wed  to  hold  intermediate  output. 


The  maior  weaknesses  of  the  language  in  comparison 
to  the  "TINMAN"  are  as  follows: 


- Parallel  processing  not  supported. 

- A general  exceptional  handling  capability  is  not 
available  in  CMS-2. 


- Powerful  I/O  caoaoi  1 1 1 ies  , as  required  by  the  " T I *J  - 
w A , are  not  supported. 


M 


- No  facilities  for  user  definable  data  types,  and  the 
associated  ability  to  define  new  operations  for  such 
data  tyoes. 


- Strong  typing,  as  required  bv  the  "TINMAN",  is  not 
rigidly  enforced  in  CMS-2 . 

In  general,  CMS-2  provides  gp  adeouate  framework  tor 


r 
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problem  solving.  Since  the  base,  or  kernel,  of  the 
lanquaoe  constitutes  the  entire  language,  it  is  a fairly 
complex  one.  For  example,  the  documentation  lists  179 
<ev-words.  Tne  language  allows  some  machine-dependent 
ooerations;  such  operations  include  register  use,  word 
size  and  internal  data  reore  lentat ions . Certainly  these 
constructs  can  be  removed,  bur  at  some  expense.  As  is 
tne  case  with  other  languages  implemented  on  a variety  of 
machines,  a number  of  imD l e ientat ion  dependencies  have 
crept  into  CMS-2.  Aoolicati»ns  programs  taking  advantage 
of  such  installation  depender t features  miy  have  to  be 
modified  to  operate  on  other  machines. 


CMS-?  programs  tend  to  be  hard  to  r»ad,  due  to  the 
use  of  a limited  character  set  C02fe  codes),  as  well  as 
the  use  of  three  distinct  comment  co(ventions.  Since 
•nai  n tainab  i 1 i t v is  a malo:  DOD  goal,  readability  ot  oro- 
grams  is  nigniy  desiraDle. 


Modification  of  CMS-'/J  to  fully  meet  the  DOD  "TINMAN" 
requirements  is  possible,  Some  features,  sucn  as  an  ex- 
tended pointer  capability  and  automatic  range  checking, 
can  be  easily  included.  > ther  features,  such  as  expanded 
array  and  reccrd  handlin'  capabilities,  recursive  control 
structures,  powerful  I/O  capabilities,  Parallel  process- 
ing and  strong  typing  ciuld  Prove  to  be  costly,  both  In 
terms  of  time  and  m;ney.  In  .'act,  the  modi  f ications 
necessary  to  incoroorat*  the  latt/r  capabilities  would 
destroy  much  of  the  flavor  of  CM* -2,  as  it  is  known  to- 
aay. 


